Resumen
El mantenimiento preventivo en un automóvil reduce significativamente el tiempo en que éste se encuentra fuera de funcionamiento; sin embargo, saber con mayor exactitud cuándo se debe realizar este tipo de trabajos y/o reparaciones no es una ciencia cierta. Los talleres mecánicos usualmente proveen de mantenimientos reactivos y hasta el momento no cuentan con una herramienta que le indiquen al usuario cuándo se debe hacer la siguiente visita.
Con la utilización del razonamiento basado en casos, se construyó un sistema informático que toma y procesa información tanto de los estándares del fabricante como también valores ambientales propios del tipo de uso del automóvil, obteniendo así una mayor precisión sobre el comportamiento en carretera y por tanto se puede saber con mayor certeza cuándo se debe reparar nuevamente el automóvil.
Una vez concluído el proyecto, se pudo observar cómo al adaptar la técnica sugerida con una base de datos en crecimiento, tanto de información relevante al automóvil como también de sus similares, los talleres mecánicos que utilicen esta herramienta, son capaces entonces de brindar un mejor servicio a sus clientes, y éstos últimos se ven beneficiados ya que pueden planear mejor el momento de revisiones y mantenimiento, mejorando de esta forma la condición general del automóvil.
Palabras clave: Predicción de mantenimiento; predicción vida útil; uso de repuestos; aplicación de predicción; CBR; RBC
Abstract
Preventive maintenance for an automobile, significantly reduces the time of a vehicle to be out of service; nonetheless, knowing when any kind of maintenance or repairs should be done to the automobile it is not an exact science. Mechanical and repair shops usually provide service as a reactive measure, and up to this date, there are not automated tools to let know the user when should the next visit or repair must be done.
Utilizing case based reasoning, an informatics automated system was build, so that it takes and processes data including manufacturer’s standards and the vehicle’s environment, converting it into information, generating a more precise data about the automobile so that it can predict when should the next repair occur.
Once the project concluded, it allowed to observe how the technic chosen with a growing database with relevant information about the automobile and it’s similar, all the repair shops who will use this tool, will be capable to give a better service for their customers, and also automobile owners will get benefits, since they can now plan ahead checkups and repairs which in the end will transform in a better vehicle overall health and time saving for its owners.
Keywords: Maintenance prediction; lifespan prediction; repair parts use; prediction system; CBR; RBC
Introducción
Con la variedad de automotores, situaciones ambientales y su uso, cada vez es más la información y componentes tanto mecánicos como electrónicos que poseen los automóviles, que pueden provocar cientos de fallas inesperadas a sus dueños.
Debido a la gran cantidad de variables existentes, no se cuenta hasta el momento con herramientas que ayuden al conductor y su proveedor de servicio obtener información certera sobre los periodos en que se debe realizar mantenimientos. Analizando la situación, se planteó el uso de una técnica que ayude a las conclusiones sobre estas situaciones, utilizando conocimiento específico de casos y problemas en situaciones similares (1).
Desde siempre, los humanos tomamos decisiones basado en problemas y resultados anteriores, por lo que almacenar esta información y hacer que un sistema computacional deduzca por medio de la historia, puede por tanto ayudar con predicciones en diferentes ámbitos, y ser adaptados en particular al proyecto en cuestión.
Para la determinación de la vida útil de la reparación, se utilizará una metodología de razonamiento basado en casos “Case-Based Reasoning”, el cual se basa en solucionar un problema basado en problemas similares que han sucedido anteriormente. El CBR, nace a partir del trabajo de Schank y Abelson en el año 1977; a finales de 1980, el programa de estados unidos DARPA, creó una serie de talleres que llevaron al desarrollo de una herramienta CBR llamada Cognitive System’s ReMind (2).
La necesidad del CBR, nace a partir del hecho de que la computación debe ser cada vez más eficiente; por lo que si ya se sabe la solución a un problema, la idea es reutilizar este conocimiento y no volver a realizar todo el mismo proceso para obtener la respuesta.
Desde hace muchos años han existido esfuerzos contundentes con respecto a la solución eficiente y reutilización de conocimiento, ejemplo de ello son los patrones de diseño y el case based reasoning (2).
Esta es una técnica que ha permitido construir sistemas que mejoren la forma de dar soporte y atención a clientes por ejemplo, así como también se ha explotado su uso en aplicaciones médicas y legales.
El sistema de pronósticos para un taller mecánico, es un sistema que consiste en una herramienta que ayude a los talleres de automóviles y sus clientes a determinar con una mejor exactitud la vida útil de cada una de las reparaciones realizadas en sus vehículos.
Existen algunos de los tipos de mantenimientos que se le dan a un automóvil y que es de conocimiento de los choferes, como por ejemplo cada cuánto se debe realizar cambios de aceite, filtros, escobillas, etc.; Existen también estándares dados por los fabricantes sobre cada cuánto tiempo se deben ejecutar revisiones de las diferentes partes del automóvil; la herramienta acá especificada, tiene como objetivo principal indicar a los dueños de los automotores, pero no existe actualmente en el mercado investigado, una herramienta que sea capaz de indicar a la hora de facturar, la fecha estimada de la próxima revisión a causa del mismo problema recién tratado.
Con éste sistema, será posible transformar el proceso de reparaciones de automóviles, ya que la idea es que cada vez que una persona se acerque al taller mecánico para realizar un trabajo en su carro, el sistema sea capaz de decirle cuándo deberá regresar para realizarle el mantenimiento respectivo, de forma tal que el usuario no tenga que esperar a que se vuelva a dañar para llevarlo nuevamente al taller.
Una de las temáticas más importantes, es poder crear una cultura donde el chofer sepa cuánto tiempo le va a durar una reparación, con lo que entonces él podrá prevenir tanto económicamente la siguiente inversión que tendrá que realizar al automóvil, así como ayudarse con la planificación del tiempo en el momento que deba regresar al taller mecánico.
Inicialmente, el taller mecánico debió adaptarse a la utilización del nuevo sistema, ya que se estaba automatizando de igual forma muchas de sus tareas diarias que anteriormente se realizaban de forma manual. Una vez alimentado el sistema con datos iniciales o “Training Sets”, y con los datos del día a día, el impacto del sistema se notará con los diferentes clientes del taller, debido a que como nuevo servicio, el taller le entregaba al cliente información referente a las fechas aproximadas de sus próximas revisiones o cambios de repuestos.
El sistema podrá ir mejorando cada vez más, basado en la información inicial además de que va ir adquiriendo experiencia conforme va pasando el tiempo, de forma tal que el producto final se estará “autorenovando”, al tomar éste los datos diarios de las diferentes reparaciones, provocando que cada día se acerque más a la realidad.
En las siguientes secciones se discutirá sobre trabajos relacionados, donde podemos ver algunas comparaciones de la técnica relacionada vrs otras técnicas computacionales. Se mostrarán los objetivos iniciales del sistema, el planteamiento del modelo conceptual y la metodología seleccionada para realizar el desarrollo. Finalmente se cuenta con una sección de pruebas realizadas y las conclusiones del proyecto.
Trabajos Relacionados
Las aplicaciones de CBR pueden clasificarse principalmente en dos tipos (2): Tareas de clasificación y Tareas de síntesis.
Las tareas de clasificación son aplicaciones que tienen ciertas características en común. Un nuevo caso se compara con los que ya existen para determinar qué tipo, clase o caso es. La solución del caso más cercano en la clase es reutilizado.
Este tipo de CBR se ha utilizado para realizar Diagnósticos, Predicciones, Asesorías, Controles de procesos y Planeaciones.
A nivel de diagnóstico, se han creado herramientas que ayudan a realizar diagnósticos a nivel médico y de fallas de equipos.
Con respecto a la predicción, se desarrollan herramientas que ayudan a pronosticar desde fallas de equipos hasta aspectos como rendimiento de la bolsa de valores.
Si hablamos de asesorías (assessment), por ejemplo se encuentran aplicaciones que ayudan con el análisis de riesgo, esto para ser utilizado en bancos y aseguradoras, así como también se puede ayudar para realizar estimaciones de costos de proyectos.
En cuanto a control de procesos, la técnica se puede utilizar para realizar controles de equipo de manufactura. Y si de planeación se habla, la técnica ayuda en procesos de planear por ejemplo viajes y también horarios de trabajo.
Las tareas de síntesis por otro lado, tienen como objetivo volver a crear una solución, combinando las soluciones previas, por ejemplo diseñar una nueva casa combinando partes de otras casas.
Existen pocos de estos sistemas, pero involucran tareas como Diseño, la creación de un nuevo artefacto por medio de la adaptación de elementos de previos.
Las tareas de síntesis también pueden ayudar con la planeación, en casos como por ejemplo, la creación de nuevos planes a partir de elementos existentes.
En cuanto a ser aplicado en aspectos de configuración, se puede utilizar en por ejemplo la creación de nuevos horarios a partir de horarios ya existentes.
Si se comparan los dos tipos de tareas mencionadas anteriormente, se puede decir que las tareas de clasificación por lo general son mejores en muchos casos, sobre todo en casos computacionales que utilizan el inductive retrieval para clasificar las tareas (2).
EL CBR, ha resultado ser una técnica muy provechosa en diferentes ámbitos, tanto computacionales como no; existen muchos sistemas entre ellos podemos encontrar:
-
PROTOS que es un sistema de diagnóstico médico en el ámbito otorrinolaringología (3)
-
CASEY Sistema inteligente centrado en el dominio de los fallos cardíacos que combina Razonamiento Basado en Casos y Sistemas Basados en Reglas. (3)
-
BOLERO utilizado para planear tratamientos médicos (3)
-
IKBALS II y IKBALS III, proveen información sobre cómo pagar sobre compensaciones de accidentes y créditos respectivamente (4)
-
Análisis de gestión de riesgos en software (5)
En cuanto a sistemas para automóviles, no se ha encontrado una herramienta como la acá propuesta; sin embargo si existen algunos datos estándares dados por compañías fabricantes sobre los periodos en que se debe realizar algún tipo de reparaciones preventivas; se encontró de igual forma, manuales de forma digital como por ejemplo manuales Mitchell, manuales ALLDATA (6), y se puede utilizar también la ayuda AutoData que son manuales en el que el fabricante describe un tiempo estándar en el que se debe reemplazar partes de los automóviles.
Durante mucho tiempo, se ha buscado los mejores mecanismos de inteligencia artificial para que sistemas de información puedan aplicarlos y obtener resultados de forma concisa. Existen múltiples técnicas que pueden ser utilizados en diferentes áreas; se muestra a continuación una comparación entre diferentes técnicas incluyendo al CBR.
En el cuadro 1, se muestra un estudio realizado para visualizar la eficiencia del método de razonamiento basado en casos vrs análisis estadísticos, se observa que los resultados finales arrojan un promedio de 93.2% con la técnica inductiva vrs un 61% con la técnica de análisis de discriminación lineal, mostrando de esta forma la eficiencia en cuanto a la resolución de casos utilizando el CBR.
Compración del CBR vrs Sistemas Expertos basados en reglas
En el cuadro 2, se aprecia una comparación de la implementación con el razonamiento basado en casos vrs sistemas basados en reglas.
Técnica Inductiva (Inductive Retrieval)
Involucra una técnica llamada Inducción, desarrollada por investigadores del aprendizaje de máquinas, donde la idea es extraer las reglas o construir un árbol de decisión basados en los datos del pasado. En los sistemas CBR, el caso se analiza por un algoritmo de inducción para producir un árbol de decisión que clasifica o indexa los casos. El algoritmo más utilizado es el ID3 (2).
El ID3 requiere un atributo a ser precedido (bueno, malo, muy bueno, muy malo, por ejemplo), por lo que hay que buscar cuáles son los índices que nos van a dividir el árbol. El árbol puede dividirse en varios atributos que nos vayan indicando el camino para llegar a resolver el caso (2), se muestra un ejemplo de este proceso en la figura 1.
Ventajas y Desventajas del Case-Based Reasoning
Existen una numerosa cantidad de ventajas utilizando el CBR, en dominios donde existe poco dominio de la teoría, los modelos razonadores no son prácticos. Cuando la relación entre los atributos de los casos y la solución o resultado no se entiende bien para representarlo en reglas, o cuando el radio de casos que son “excepciones a la regla” es muy alto, los sistemas basados en reglas son poco prácticos. CBR es especialmente útil en este tipo de situaciones ya que modela las excepciones y los casos (7).
El CBR es también muy práctico a la hora de explicar o justificar una solución. Cuando la teoría del dominio es débil, es difícil justificar o explicar una posición. Buscar una analogía con un caso parecido en el pasado puede ser un mejor argumento. CBR soporta el aprendizaje en dominios donde no se cuenta con una fuerte comprensión del modelo de dominio (7).
Existen también desventajas en utilizar el CBR, pues si no se cuenta con suficientes casos similares, la solución que se obtenga puede ser inapropiada. El CBR también, puede que no reconozca un nuevo tipo de problema, esto es cuando un nuevo caso se distingue de casos anteriores por una característica que no está representada en los índices, entonces el CBR no va a poder reconocer la distinción (7).
Los sistemas CBR son relativamente fáciles de construir. Sin embargo es difícil que los expertos expliquen sus reglas de decisión, por lo general son personas que pueden contar historias sobre sus experiencias, lo cual facilitan el desarrollo de los casos (7).
Objetivos del Proyecto
El sistema de Pronósticos de Taller, viene a automatizar funciones diarias como por ejemplo asignación de tareas entre empleados, control y consulta de reparaciones realizadas, control y manejo de clientes, facturación entre otros, sin embargo, al desarrollar este sistema, el objetivo principal es que, con base en información sobre los clientes, sus automóviles y las reparaciones que se les ha realizado anteriormente, pueda generar entonces un diagnóstico sobre la ocurrencia de fallas en el tipo de reparación realizada.
Como puntos importantes a destacar, debe ser que el sistema debe ser lo suficientemente amigable para que personas que no están familiarizadas con el manejo de altas tecnologías, adopten el sistema sin mayor problema y que lo vean como una herramienta que les ayude a mejorar en sus tareas diarias.
Lo acá planteado pretende construir una base de datos en constante crecimiento que permita aplicar la técnica de razonamiento basado en casos de forma tal que el software pueda con el tiempo tener mayor exactitud a la hora de que se realicen las predicciones para resolver cuánto es la vida útil de una reparación en específico; por lo que el proyecto en su forma principal, contempla el desarrollo e implementación de un algoritmo de pronóstico de vida útil, inicialmente utilizando datos entregados por el taller, de forma que se cargue a la base de datos un set inicial para que el algoritmo empiece a realizar análisis y a almacenar los resultados.
Idealmente, la base de datos con reparaciones, se integrará con varios talleres, de forma tal que se pueda ir construyendo una base de datos de conocimiento más globalizada, y por lo tanto con el tiempo las predicciones puedan ser más exactas, no importando así si el cliente cambia de taller, ya que los datos pueden ser compartidos entre la misma red de talleres.
Metodología de Desarrollo
En el escenario para el que se realizó el trabajo, se encuentra con que el personal del taller mecánico no tiene experiencia en el desarrollo e implementación de sistemas de información, por lo que la metodología utilizada fue un prototipo incremental, de forma tal que los principales afectados pudieran ir observando las diferentes funcionalidades del sistema conforme se avanza en el proyecto (9).
Se planteó un ciclo de vida de desarrollo de software estándar con las siguientes etapas:
-
Definición de requisitos del sistema
-
Análisis del sistema
-
Especificación de los requisitos del prototipo
-
Diseño del prototipo
-
Desarrollo o codificación del prototipo
-
Implementación y prueba del prototipo
-
Refinamiento iterativo de las especificaciones del prototipo
-
Implementación del sistema final
Tomando en cuenta los resultados encontrados con respecto a la efectividad de diferentes técnicas, se determinó que en este caso el Case-based reasoning (CBR), o el razonamiento basado en casos, podía adaptarse al problema a resolver, ya que se parte de que los problemas a resolver tienen cierto grado de comportamiento, y tal como se ha explicado anteriormente, es el proceso de resolver un nuevo problema basado en la solución de problemas similares que hayan ocurrido en el pasado (10) aplica de forma casi perfecta al taller mecánico.
De acuerdo con A. Aamodt, E. Plaza (11) el razonamiento basado en casos no solamente es un método de razonamiento computacional, sino que también es la forma en que el pensamiento humano se comporta diariamente para resolver problemas. Un argumento más radical, indica que todo razonamiento se basa en la experiencia de casos del pasado.
Leake David (10), nos indica que tal como lo hace el cerebro humano, contamos con un almacenamiento de datos creando una memoria para el CBR, de forma que se tengan tanto el problema como la solución al problema. Cada vez que se presente un nuevo caso o problema, el sistema debe de ir a buscar alguna similitud con los casos existentes y resueltos.
Dadas las definiciones anteriores, nos enfocamos entonces a los siguientes pasos:
Obtener Información:
-
Diseñar un algoritmo que permita buscar en la base de datos casos anteriores que sean relevantes al caso en cuestión.
Reutilización:
-
Mapear la solución basada en el caso previo al problema y adaptarlas al nuevo caso
Revisar:
-
Contando con la solución previa, realizar el pronóstico de la siguiente ocurrencia y revisar resultados
Retener:
-
Después de que la solución se ha adaptado al problema, almacenar los resultados y la experiencia como un nuevo caso en la base de datos
A manera de comprender mejor lo explicado acá, en la figura 2 se muestra el proceso realizado en el Razonamiento Basado en Casos.
Análisis y Diseño
Como siempre, al inicio de todo desarrollo, es importante rescatar los puntos más importantes involucrados dentro del proceso a automatizar, de forma que el desarrollador pueda empezar a familiarizarse con el ambiente.
Un modelo de conceptual, captura los tipos más importantes de objetos en el contexto del sistema. Los objetos del dominio representan las cosas que existen o los eventos que suceden en el entorno en el que trabaja el sistema (8). En la figura 3, se visualiza los conceptos más importantes, identificados, que intervienen en el sistema.
En la figura 4, se muestra un diagrama de la forma en que se estructurarán los módulos del sistema.
La arquitectura del sistema se modelará tipo Cliente-Servidor. En el cliente se estará ejecutando la capa de presentación, y en el servidor, la capa de lógica del negocio y la base de datos. La arquitectura debería tener también los componentes o módulos internos generales para hacerla más pertinente, para un mejor entendimiento se muestran los subsistemas en la figura 5.
Desarrollo
Árbol de decisión
Haciendo utilización de la técnica inductiva del CBR, se procede a identificar los índices pertinentes de acuerdo con el problema a resolver. En este caso se procedió a realizar una jerarquía de prioridades por los índices más importantes, de acuerdo con el conocimiento del usuario experto.
Los índices definidos han sido:
-
Tipo de Combustible
-
Año del automóvil
-
Tracción
-
Modelo
-
Marca
-
Tipo de motor
Cada vez que un automóvil llega al taller para ser reparado, se almacena en la base de datos la fecha, el tipo de servicio brindado, y las diferentes características del automóvil, de esta forma se va creando la base de datos de los diferentes casos, conforme la base de datos vaya creciendo, la búsqueda obtendrá información mucho más certera.
A la hora de realizar la facturación, el sistema irá a la base de datos y almacenará la información actual como un nuevo caso. Primero se busca si el cliente ya ha recibido este tipo de servicio para el mismo automóvil anteriormente. De ser así, el sistema procederá a almacenar un nuevo caso donde se indicará la cantidad de días de vida útil que tuvo la reparación reciente, y se almacenará dicho dato junto con el pronóstico realizado anteriormente; luego se procederá a realizar una búsqueda de todos los casos anteriores similares o el más cercano al servicio que acaba de ser brindado al cliente, con base a esto, el sistema calculará la cantidad de días de vida útil que se tiene en promedio para la reparación actual.
En caso de no conseguir un dato de casos similares, se tomarán datos del fabricante si existen en la base de datos.
Para definir cuáles son los criterios de búsqueda, se contempló con el usuario, de acuerdo a su juicio, la prioridad de búsqueda de casos en la base de datos, y esta es la prioridad asignada:
-
Misma marca, modelo, tracción, combustible, año y tipo de motor
-
Misma marca, modelo, año y motor
-
Misma marca, modelo y año de fabricación
-
Misma marca, modelo y motor
-
Misma marca, año y motor
-
Misma marca, modelo, tracción, combustible y año
-
Misma marca, modelo y año
-
Misma marca, modelo, tracción y combustible
-
Misma marca, modelo y tracción
-
Misma marca, modelo y combustible
-
Automóviles de la misma marca y modelo
-
Automóviles de la misma marca y motor
-
Automóviles de la misma marca y año
-
Automóviles que han recibido el mismo tipo de servicio
-
Automóviles de la misma marca
Esta prioridad puede ser visualizada en la figura 6.
Resultados Obtenidos
Una terminado el desarrollo de acuerdo con los estándares definidos, se procedió a realizar pruebas para determinar si se cumplió a cabalidad con las expectativas del cliente, las pruebas realizadas fueron controladas en diferentes escenarios, para poner a prueba el pronóstico que realiza el sistema.
Se alimenta el sistema con una serie de casos y éstos fueron realizados junto con el experto en mecánica automotriz, estos casos son hipotéticos ya que el sistema al iniciar no cuenta con datos históricos del taller, y en muchos casos, es necesario que transcurran gran cantidad de días para comprobar su validez; se plantearon entonces los siguientes escenarios sin embargo no son datos reales, ya que el taller realiza reparaciones que por lo general no es preciso volverlas a hacer antes de un año.
El primer caso, es el de un Hyundai Accent, año 1995, presenta un fallo donde la aceleración no es constante, y tiene problemas en las bujías.
El primer caso, es el de un Hyundai Accent, año 1995, presenta un fallo donde la aceleración no es constante, y tiene problemas en las bujías.
De acuerdo con los datos del sistema cargados a partir de instrucciones del fabricante, un automóvil de este tipo se le deberá hacer cambio de bujías cada 48 meses o cada 60mil kilómetros.
El automóvil se reparó en febrero del 2003, y el kilometraje en aquel momento era de alrededor de 689000. El sistema encontró con que debería regresar 48 meses después es decir en enero del 2007 o cuando cumpliera con los 749000 kilómetros.
El automóvil llegó nuevamente en Octubre del 2006, con 749100 kilómetros, por lo que el pronóstico ahora es de 45.3 meses y de 60100 kilómetros. Como se puede ver en este caso, el conductor hizo un promedio mayor de kilómetros por mes por lo que la fecha del nuevo cambio se adelantó. Estos valores se vieron afectados, ya que anteriormente en la base de datos se encontraban registrados el mismo tipo de servicio para este mismo automóvil, por lo que se toma como base los días y kilometraje de los servicios anteriores, además de los días promedios y kilometraje que tardó en ésta última reparación. Como dato importante es preciso mencionar que en este caso se utilizaron datos de repuestos de bujías de punta de diamante, los cuales tienen una mayor vida útil.
El siguiente caso se trata de un automóvil al que se le cambió la faja de distribución, de acuerdo con la base de datos, su siguiente cambio antes de que el motor falle, deberá ser alrededor de 4 años más y cuando se tenga un máximo de 190000 kilómetros.
De acuerdo con los datos obtenidos del sistema AutoData y validándolas con el juicio experto, se determina que 80mil kilómetros es el dato exacto de cuándo debe ser cambiada la faja de distribución.
Otro automóvil de la misma marca y modelo le fue reemplazado la faja de distribución en Diciembre de 2007, por lo que el sistema buscó datos en la base de datos, al ser la primera vez que visitaban el taller, entonces el sistema tuvo que buscar los datos de automóviles revisados anteriormente, y le pronosticó que su vida útil sería hasta que alcanzara los 270050 kilómetros, es decir 80000 kilómetros.
El tercer caso con el que se puso a prueba, toma en cuenta un automóvil que se le cambió el aceite de Transmisión en Diciembre del 2007, dicho filtro debería de cambiarse en 1 año o 20mil kilómetros. Se muestra la pantalla con los resultados obtenidos.
Con el cuarto caso, se pone a prueba un automóvil al que se le cambió los compensadores en Diciembre del 2006, la vida útil de dicha reparación de acuerdo con los datos de AutoData y el criterio experto nos dice que es de 1 año o 15mil kilómetros.
El mismo automóvil regresa al taller hasta marzo del 2008 con un total de 100500 Km, lo cual indica que realizo un promedio de 500 kilómetros más de lo pronosticado lo que implica que para la próxima revisión se regresará cuando tenga 115500 Kilómetros recorridos.
Para validar los resultados del sistema, se elaboró una pequeña encuesta a tres diferentes talleres, exponiendo los casos y resultados pronosticados por el sistema, de forma tal que validen la correctitud de los datos de basado en su criterio experto.
De acuerdo con los datos mostrados a los diferentes expertos en el área, se tiene que por lo general los talleres mecánicos no cuentan con herramientas informáticas especializadas que le ayuden a generar un pronóstico sobre la vida útil de las reparaciones, y que algunos aunque cuentan con algún otro tipo de software que les complementa su conocimiento, en realidad no cuentan con una herramienta que les facilite los procesos diarios de documentaciones sobre reparaciones realizadas, facturación y que además se obtenga un valor agregado para el cliente a la hora de indicarle su próxima fecha de revisión.
Entre los casos presentados a los talleres, se puede concluir que todos los expertos concuerdan con el hecho de que los resultados arrojados por el sistema son confiables de acuerdo con su experiencia.
Los encuestados también están muy anuentes a utilizar dicho sistema, y consideran que sería de mucha utilidad tanto para ellos como para el cliente, ya que además de agilizarles el proceso de facturación y registro de reparaciones, clientes, preformas, etc, le darían al cliente un valor agregado al indicarles el promedio de la vida útil de la reparación recién hecha.
Conclusiones y Trabajo Futuro
En sistemas de pronóstico que incurren en un árbol de decisión con un comportamiento un tanto estático, la mejor técnica a utilizar es el razonamiento basado en casos de forma inductiva.
A la hora de realizar un árbol de decisión es de suma importancia lograr con el usuario un consenso sobre cuáles serán los índices y sus respectivas prioridades a utilizar en la búsqueda de los casos.
El desarrollo de proyectos de sistemas de información para ser utilizados por personas que están bastante ajenas al área, es mucho mejor realizarlo por medio de un prototipo incremental, ya que es más fácil la comprensión por parte del usuario.
El sistema de pronósticos es una herramienta la cual irá evolucionando con el tiempo y la cantidad de datos serán los que hagan que los pronósticos sean más adecuados a la situación de nuestro país, sin embargo las pruebas que se han podido realizar son hipotéticas basándose en el conocimiento experto del dueño del Taller, ya que éste no mantenía registros detalladazos sobre las reparaciones que se han realizado a los diferentes automóviles en los últimos años.
En una futura mejora del proyecto, se recomienda hacer uso de otros índices adicionales como por ejemplo el tipo de usuario del automóvil y género ya que esto haría que el pronóstico se adecue un poco mejor.
Una variante también que se puede realizar es hacer intervención por parte del usuario en el pronóstico, de forma tal que se tome en cuenta también el juicio experto.
Como mejora también al sistema, se recomienda realizar un módulo que realice envíos de mensajes y/o correos a los clientes para hacerles recordatorios sobre sus próximas revisiones.
Crear una red de talleres con información compartida sobre las diferentes reparaciones realizadas a los automóviles, brindaría a los usuarios una mejor información con respecto a su automóvil y su respectivo pasado, de forma que cuando el automóvil cambie de dueño y sea llevado a un taller diferente, no se pierda el historial, y mas bien contribuya con una mejora en los pronósticos.
Sería recomendable también agregar otro tipo de información que puedan convertirse en índices relevantes para la toma de decisiones como por ejemplo el área en el que el automóvil transita constantemente, ya sea área rural o urbana, género del conductor, etc.
Referencias
- W. J. S. B. a. M. C. Boris Campillo-Gimenez, «Improving Case-Based Reasoning Systems by Combining K-Nearest Neighbour Algorithm with Logistic Regression in the Prediction of Patients’ Registration on the Renal Transplant Waiting List,» PMC, 2013.
- I. Watson, Applying Case-Based Reasoning: Techniques for Enterpise Systems, Morgan Kaufmann, 1997.
- L. R. Wong Portillo, «Un modelo de Razonamiento Basado en Casos para la Captación de Requisitos en el desarrollo de proyectos de software,» 2012.
- J. Zelesnikov, «InfoJur,» (En línea). Available: http://www.egov.ufsc.br/portal/sites/default/files/anexos/2662- 2656-1-PB.htm.
- S. M. R. Rodríguez, «Modelo de un sistema de razonamiento basado en casos para el,» vol. 4, 2011.
- ALLDATA, ALLDATA Diagnostic and Repair Information.
- D. B. Morris, «Case Based Reasoning,» AI/ES Section of the American Accounting Association, 1995.
- I. Sommerville, Software Engineering, Addison-Wesley, 2010.
- D. B. Leake, «CBR in Context: The Present and Future,» 1996. (En línea). (Último acceso: 2 11 2014).
- E. P. Agnar Aamodt, «Case-Based Reasoning: Foundational Issues, Methodological Variations, and System Approaches,» vol. 7, nº 1, 1994.
- Y. R. C. Y. T. R. Dasiel Cordero Morales, «Sistema de Razonamiento Basado en Casos para la identificación de riesgos de software,» 2013.
- G. J. Jacobson I, « El Proceso Unificado de Desarrollo de Software,» 2005.
- J. M. F. Florentino, «Sistemas híbridos neurosimbólicos: Una revisión, Inteligencia Artificial,» 2000
Fechas de Publicación
-
Fecha del número
Jan-Mar 2019
Histórico
-
Recibido
15 Feb 2018 -
Acepto
29 Mayo 2018