ES2279588T3 - Sistema para el diagnostico dinamico de las condiciones de funcionamiento de un aparato. - Google Patents

Abstract

Una plataforma de operación incluye un procesador, un medio de almacenamiento e interfaces de usuario, que incluyen una pantalla de visualización, estando acoplado el procesador a un analizador (elemento físico) del motor y concebido para ser acoplado a un escáner para bajar datos de vehículos a ordenadores de a bordo. El sistema almacena bibliotecas de información relativas a la identificación de vehículo, síntomas que miden la capacidad de conducción que presentan los vehículos, sistema de vehículo y pruebas de componente y códigos de servicio que pueden ser registrados por el ordenador de a bordo del vehículo. El soporte lógico del sistema permite que el usuario introduzca una identificación del vehículo en prueba, y en un modo de funcionamiento, muestra una biblioteca de fallos, como síntomas o códigos de servicio, a partir de los cuales el usuario puede seleccionar aquellos presentados por el vehículo, sobre los que el sistema selecciona desde la librería aquellos ensayos relativos aldiagnostico de las causas seleccionadas de los fallos y los muestra en un orden dispuesto jerárquicamente en función de la probabilidad o éxito en el diagnóstico de los fallos. El usuario puede seleccionar, entonces, e iniciar cualquier modo de visualización. En otros modos, el sistema inicialmente muestra una o más bibliotecas de pruebas de sistema o componentes, desde las cuales el usuario selecciona aquellas estimadas apropiadas, sobre las cuales el sistema resalta iconos que pueden ser seleccionadas para iniciar los procedimientos pertinentes al test. Los procedimientos pertinentes al test pueden incluir enlacen al analizador del motor o un elemento de barrido o cualesquiera otros módulos adecuados.

Description

Sistema para el diagnóstico dinámico de las condiciones de funcionamiento de un aparato.

El invento se refiere a un método acorde con el preámbulo de la reivindicación 1.

Tal método se conoce del documento US 4.796.206. De acuerdo al método descrito el usuario selecciona el tipo de apoyo deseado, cuyo apoyo incluye un procedimiento de servido a vehículo (VSP). A continuación un procedimiento de detección de fallos (FDP) detecta fallos interrogando a datos recibidos del ordenador de a bordo. Los fallos detectados son buscados en un procedimiento de análisis de fallos y, cuando se encuentra una fila correspondiente en la tabla de análisis, el fallo correspondiente es procesado (FIP(s)).

Antecedentes del invento

El presente invento se refiere generalmente a sistemas de diagnóstico y pruebas para máquinas u otros aparatos de funcionamiento, y tiene particular aplicación a vehículos de automoción, particularmente vehículos impulsados por motores de combustión interna. Aunque el invento se describe en el contexto de un sistema analizador de motor, los principios del presente invento se pueden usar con otros tipos de sistemas de diagnóstico de vehículos, tales como sistemas de servicio y prueba de aire acondicionado, sistemas de equilibrado de ruedas, sistemas de análisis de emisiones de gases en automoción y similares, y también se pueden usar con aparatos no de automoción.

Hasta ahora se han usado, por tanto, varios tipos diferentes de herramientas de diagnóstico para ayudar al diagnóstico y reparación de situaciones de fallo en vehículos de automoción. Tales herramientas incluyen analizadores de motores, que están diseñados para supervisar una variedad de condiciones de funcionamiento de un motor de combustión interna y lectores para descargar datos desde ordenadores de a bordo del vehículo. Además, herramientas de diagnóstico pueden incluir tales herramientas estándar de tipo de laboratorio como osciloscopios de laboratorio, voltímetros ohmiómetros digitales ("DVOM") y similares. Básicamente, estas diversas herramientas de diagnóstico se encuentran en dos categorías, proveedores de datos y plataformas de diagnóstico, aunque algunos analizadores de motores, tales como el descrito en la patente de EEUU número 5.250.935, pueden interferir con lectores y pueden funcionar en un modo de simula un osciloscopio de laboratorio y/o un DVOM.

Los proveedores de datos (por ejemplo, DVOMs, lectores y osciloscopios de laboratorio), simplemente dan los datos al usuario y el usuario debe determinar sus propios procedimientos de prueba de diagnóstico y sus conclusiones. Las herramientas de proveedor de datos recaen completamente en la capacidad del usuario para decidir qué herramienta usar y qué hacer con los datos proporcionados, incluyendo la selección de pruebas que deben realizarse, interpretar los resultados de las pruebas y similares.

Los productos de plataforma, por ejemplo, analizadores de motor, son típicamente sistemas prestigiosos capaces de realizar una variedad de diferentes tipos de pruebas. Pueden proporcionar al usuario con secuencias automáticas de pruebas que prueban sistemáticamente el vehículo en un orden particular y entonces proporcionan conclusiones de diagnóstico basadas en los resultados de las pruebas. Los productos de plataforma, tales como analizadores de motor, se enfocan usualmente en tipos particulares de problemas o sistemas particulares de vehículos. Puede llevar considerable tiempo para conectar todos los cables y realizar las pruebas variadas, y el usuario debe decidir que producto usar y como deben ser integrados los datos de las pruebas en un diagnóstico general.

También hay sistemas de información disponibles como paquetes de software independientes que proporcionan información de servicio e información de reparación para una amplia variedad de vehículos de automoción. Sin embargo, en tales productos es difícil navegar por ellos para encontrar la información necesitada para el diagnóstico y reparación y están basados típicamente solo en información de diagnóstico de equipos originales, y pueden no contener información de problemas experimentados en el campo durante la vida del vehículo.

Sumario del invento

Es un objeto general del invento proporcionar un método de diagnóstico mejorado que evite las desventajas de tales sistemas anteriores mientras que facilita ventajas adicionales de funcionamiento y estructurales.

Este objeto se alcanza con el método de la reivindicación 1.

Una característica importante del invento es la provisión de un sistema de diagnóstico que guiará al usuario en la selección de pruebas a realizar y disminuir el funcionamiento de las pruebas no necesarias.

En relación con la característica anterior, una característica importante adicional es la provisión de un sistema de diagnóstico del tipo establecido que permite selección de pruebas basadas en fallo.

Todavía otra característica importante es la provisión de un sistema de diagnóstico del tipo establecido que facilite la modificación y actualización para incluir información de problemas y remedios experimentados en el campo durante la vida del aparato en prueba.

Todavía otra característica importante es la provisión de un sistema de diagnóstico del tipo establecido que pueda ser integrado fácilmente con plataformas de equipo físico de diagnóstico existentes previamente.

En relación con la característica anterior, todavía una característica adicional importante es la provisión de un sistema de diagnóstico del tipo establecido que sea modular.

Incluso otra característica importante es la provisión de un sistema de diagnóstico del tipo establecido, que esté diseñado para clasificar pruebas seleccionadas en un orden más probable de diagnosticar con éxito un problema del aparato.

Otra característica importante es la provisión de un sistema de diagnóstico del tipo establecido que incluya almacenamiento de los resultados de aplicaciones de usuario del sistema, para incorporación posterior en actualizaciones del sistema.

Breve descripción de los dibujos

Con la finalidad de facilitar un entendimiento del invento, en los dibujos que se acompañan se ilustra una realización preferida de él, de cuya inspección, cuando se considera en relación con la siguiente descripción, el invento, su construcción y funcionamiento, y muchas de sus ventajas deben entenderse y apreciarse fácilmente.

La figura 1 es un diagrama de bloques funcional de un analizador de motor que incorpora el sistema de diagnóstico del presente invento;

Las figuras 2-5 son representaciones en pantalla de un analizador de motor que incorpora el sistema de diagnóstico del presente invento; y

La figura 6 es un diagrama de flujo de software de programa para el sistema de diagnóstico del presente invento.

Descripción de la realización preferida

Haciendo referencia a la figura 1, se ilustra un diagrama de bloques funcional de una plataforma de diagnóstico 10 que incorpora el sistema de diagnóstico del presente invento. La plataforma 10 se ilustra relacionada con un sistema analizador de motor pero, como se ha indicado antes, puede ser aplicable a otros tipos de sistemas de diagnóstico de vehículos o no vehículos. La plataforma 10 incluye equipo físico 11 de analizador de motor, que incluye típicamente un soporte 12 de cables de prueba, que incluye una pluralidad de cables de prueba y sensores adaptados para ser conectados a varios puntos de un motor asociado de vehículo y equipo físico 13 de acondicionamiento y procesamiento de señal para interconectar el soporte de cable de pruebas a un procesador central 14. Preferiblemente, la plataforma de diagnóstico 10 es una plataforma de ordenador personal ("PC") basada en Windows®, tal como la proporcionada por el analizador de motor Sun® System 500 vendido por Snap-on Diagnostics, pero se apreciará que el presente invento también se podrá usar con otros tipos de sistemas de analizador de motor, tal como el descrito en la patente de EEUU número 5.250.935. La plataforma de diagnóstico 10 incluye típicamente una interfaz de usuario, que puede incluir cualquiera de uno o más de dispositivos diferentes de entrada/salida, tal como un teclado 16, un ratón 17, un dispositivo de visualización o monitor 18 y una impresora 19. También, la plataforma de diagnóstico 10 está provista típicamente con medios de almacenamiento 20, que pueden incluir uno o más de varios tipos diferentes de dispositivos de almacenamiento de software y datos, incluyendo RAM 21, ROM 22, disquetera CD ROM 23, disquetera flexible 24 y disco duro 25. El sistema de diagnóstico dinámico del presente invento incluye software de programa, que puede ser residente en ROM 22 o que puede comprender un paquete de software independiente almacenado en cualquiera de los medios 23-25.

Un aspecto fundamental del invento es que permite un diagnóstico de conducción basado en fallos de un vehículo. En tal modo de funcionamiento basado en fallos, el sistema presenta esencialmente al usuario un menú de problemas indicados, por ejemplo, por síntomas o códigos de servicio y el usuario selecciona estos problemas que son pertinentes al vehículo en prueba. Basado en los fallos seleccionados, el sistema presenta entonces al usuario una lista de pruebas a realizar para diagnosticar la causa o causas de los fallos. Las pruebas se listan en el orden en que de serían más fácilmente efectivas para diagnosticar los fallos del vehículo, basado en la información del fabricante y experiencia de diagnosis y reparación previa con este tipo de vehículo.

Es un aspecto significativo del invento que el sistema de diagnosis es también capaz de funcionar en otros modos, a saber, un modo de Prueba de Sistema, un modo de Prueba de Componente y un modo Manual. En todos modos, excepto para el modo Manual, el sistema mostrará una o más pruebas a realizar en el vehículo de una biblioteca de pruebas de sistema y pruebas de componentes, ejemplos representativos de los que se ilustran en los dibujos.

Cualquier uso del sistema de diagnóstico del presente invento empieza con un procedimiento de identificación de vehículo para el vehículo a diagnosticar. Haciendo referencia a la figura 2, se ilustra una representación de pantalla 30 en el monitor 18, que puede ser una representación digital de tipo de ordenador. La pantalla de representación 30 ha organizado a través de su parte superior una serie de iconos 31-35, designados respectivamente "Identificación de Vehículo", "Prueba/Análisis", "Prueba Manual", "Información" y "Gestión de Almacén". Con fines de implementar el procedimiento de identificación de vehículo, se selecciona el icono 31, presentando la representación en pantalla mostrada en la figura 2. El sistema presenta al usuario un número de cuestiones o campos, tales como año del modelo, fabricante, nombre del modelo, tamaño del motor y similar, presentando cada campo al usuario un menú de valores únicos de dentro de ese campo del que el usuario puede seleccionar. El usuario hace una selección para ese campo de una manera bien conocida, tal como con el uso del ratón 17 y el valor es añadido a la llave de búsqueda de la base de datos. La figura 2 ilustra varios de tales campos y los menús asociados con ellos. Si un menú excede la longitud de su ventana asociada de presentación, el menú puede ser desplazado de una manera conocida usando un icono en la barra de desplazamiento. El sistema es dinámico en cuanto al número de cuestiones que el usuario debe responder para identificar el vehículo, permitiendo al usuario identificar el vehículo sin tener que responder ninguna cuestión innecesaria. Para realizar diagnóstico del sistema, la identificación del vehículo debe tener resolución de al menos el año, fabricante, modelo, tamaño de motor, código de motor, tipo de combustible, tipo de combustión y tipo de medición de aire para el vehículo. Durante el tiempo de ejecución, si se necesita información adicional del vehículo para realizar una prueba seleccionada, el sistema indicará y presentará así al usuario con los campos apropiados y menús para introducir la información necesitada.

Una vez que se identifica el vehículo, el usuario es capaz de empezar el diagnóstico seleccionando el icono 32 de Prueba/Análisis, que muestra una representación en pantalla similar a la de la figura 3, que presenta tres archivos diferentes 36-38, etiquetados respectivamente "Síntomas", "Componente/Sistema" y "Códigos de Servicio", correspondientes con modos de diagnóstico automáticos descritos antes. Los archivos "Síntomas" y "Códigos de Servicio" se relacionan con modos basados en fallos. Mientras que la discusión siguiente es con respecto al modo de Pruebas de Síntomas, también se aplica en general al modo de funcionamiento de Pruebas de Código de Servicio. Si se selecciona el archivo Síntoma, se muestra en el fondo en la representación de pantalla 39 de la figura 3. La representación en pantalla 39 incluye un menú 40 de síntomas que pueden ser exhibidos por el tipo de vehículo seleccionado en la representación en pantalla 30 de la figura 2, cuyo tipo de vehículo se indica en el fondo de la representación en pantalla 39, como en 41. La lista de síntomas presentados al usuario es representativo de diagnosis de síntoma de industria y soporta la mayoría de la quejas de conducción.

Es posible una lista estándar de síntomas ya que los vehículos usan tecnología común. Cada uno tiene componentes de ordenador, mecánicos, encendido y combustible que funcionan aproximadamente de la misma manera. Otros síntomas más específicos pueden ser asignados usualmente a uno o más de los síntomas de la lista principal de síntomas. Por ejemplo, un síntoma específico de "El vehículo se para cuando se toma una curva a la derecha" se ajustará bajo un síntoma menos específico de "El vehículo se para al Ralentí/Deceleración/Frenado". Las pruebas para diagnosticar el estado son generalmente las mismas. Se usa una lista estándar de síntomas ya que proporciona una interfaz consistente y filosofía de diagnóstico para todos los vehículos, promueve la familiarización del escritor de servicio y técnico y proporciona la manera más eficiente de desarrollar un sistema "en bucle cerrado" de clasificar datos de campo para síntomas y sus causas, como se discutirá más completamente después.

El usuario/técnico selecciona uno o más de los síntomas listados que son exhibidos por el vehículo en pruebas, como se determina de una entrevista con el propietario del vehículo, por ejemplo. Basado en el síntoma o síntomas seleccionados, la representación en pantalla 39 muestra una lista 42, específica al vehículo en prueba, de posibles causas del síntoma o síntomas seleccionados y una lista equivalente de procedimientos de prueba a ser realizados para comprobar para esas causas. Los procedimientos de prueba son listados en el orden de la probabilidad o posibilidad de que la prueba será exitosa al diagnosticar la causa del síntoma o síntomas seleccionados, siendo representada esta clasificación como en 43.

Al desarrollar las clasificaciones de pruebas, durante el desarrollo del software, los técnicos de grupo de enfoque evalúan cada síntoma individual en la lista de síntomas para cada vehículo específico. Basándose en su experiencia, pueden desarrollar una lista de causas para cada síntoma y determinar un procedimiento de pruebas que el usuario debe realizar para cada causa. Entonces asignan un número, por ejemplo, entre uno y cinco, a cada causa/prueba basado en:

(a)

qué pruebas son necesarias para determinar la causa de los síntomas;

(b)

el orden en el que las pruebas deben ser realizadas basado en la probabilidad de la causa; y

(c)

en el caso de más de una causa tenga igual probabilidad, clasificar las recomendaciones de pruebas por tiempo necesitado para realizar el procedimiento de prueba, con los tiempos más cortos clasificados más altos.

Hay tres criterios principales al determinar la probabilidad de causa para cada prueba, siendo, en el orden de importancia:

1.

experiencia pasada al diagnosticar el síntoma de la relación causa/prueba;

2.

conocimiento de la teoría de funcionamiento de cómo trabaja el sistema y qué sistemas o componentes serían la causa más probable para cada síntoma, y

3.

facilidad para probar y/o tiempo necesitado para realizar la prueba.

\newpage

Al valorar la clasificación, la experiencia pasada es la primera cosa a ser considerada. El técnico usa lo siguiente como una guía para valorar la clasificación:

Clasificacion	Ocurrencia
5	se ve todo el tiempo
4	muy común
3	bastante común
2	una vez durante un rato
1	aleatoriamente

Si una prueba/causa es frontera entre dos clasificaciones, el técnico usa la facilidad de la prueba como factor determinante. Por ejemplo: un síntoma particular tiene una clasificación prueba/causa de entrega de combustible clasificada entre 3 y 4. Si la prueba es fácil de realizar, es clasificada como 4. Si es difícil de realizar, es clasificada como 3. La facilidad de prueba sólo se usa como un factor de ajuste al valorar la clasificación.

Si el técnico no tiene experiencia pasada de un síntoma para la relación causa/prueba, el síntoma es examinado entonces desde un punto de vista de una teoría de funcionamiento. Dado el conocimiento del técnico de cómo funciona el sistema y compara causas/pruebas con sistemas similares, el técnico examina si hay otras probables causas/pruebas para cada síntoma. Si es así, se clasifican como sigue:

Clasificacion	Probabilidad
3	muy probable
2	probable
1	posible

Si una prueba/causa es frontera entre dos clasificaciones, la facilidad de la prueba se usa para asignar una clasificación, como se ha descrito antes.

Si, como en la figura 3, el usuario selecciona más de un síntoma y se encuentra que una causa particular es posible para más de uno de los síntomas seleccionados, la probabilidad de que esa causa sea el problema original aumentará y la recomendación para la prueba asociada se moverá más arriba en el orden de pruebas recomendadas.

Una vez que el síntoma o síntomas han sido seleccionados y los procedimientos de prueba recomendados asociados han sido representados, el usuario puede seleccionar entonces uno de los procedimientos de prueba representados y el sistema lanzará o iniciará ese procedimiento. Mientras que la representación de pantalla 39 lista un orden recomendado para realizar las pruebas listadas, el usuario es libre de realizar las pruebas en cualquier orden deseado.

La representación en pantalla 39 incluye a lo largo del fondo de la pantalla una serie de iconos 44-48, que corresponden respectivamente a módulos de sistema útiles para realizar procedimientos de prueba seleccionados Los iconos de módulo mostrados en la figura 3 son solo para fines de ilustración, y están designados respectivamente "Consejo Rápido", "Analizador", "Herramienta de Exploración", "Llave de Almacén" y "Osciloscopio de Laboratorio/DVOM".

Los consejos rápidos son artículos de información que pertenecen al síntoma del vehículo que está siendo diagnosticado. Este módulo proporciona al técnico información que permite que el vehículo sea diagnosticado con un mínimo de conexiones y pruebas. Estos consejos son creados por grupos de enfoque de técnicos basados en su experiencia para diagnosticar los síntomas seleccionados. Esta información directa puede ahorrar horas de tipo de diagnóstico. Cuando se presenta al usuario, los Consejos Rápidos son clasificados preferiblemente en el orden de importancia en una escala de, por ejemplo, 1-5, siendo 5 el más importante. La clasificación diferencia entre información "necesaria de saber" y "buena de saber".

El módulo de Llave de Almacén es un enlace de prueba que envía al usuario directamente a una biblioteca de artículos que proporciona al usuario procedimientos pertinentes de prueba de componentes de OEM.

El módulo Analizador es como un enlace a funciones de analizador de motor de la plataforma 10, mientras que el módulo de osciloscopio de laboratorio/DVOM es un enlace a funciones de osciloscopio de laboratorio y DVOM de la plataforma 10. El módulo de Herramienta de Exploración es un enlace a funciones de un explorador, tal como el vendido por Snap-on Diagnostics bajo la designación MT2500, que está adaptado para ser acoplado al ordenador de a bordo del vehículo a prueba.

Una vez que el usuario selecciona la prueba a ser realizada, el sistema interroga la base de datos de la biblioteca de pruebas para determinar qué módulo o módulos soportan la prueba en particular a realizar y entonces permitirá y resaltará los iconos correspondientes. Cuando un procedimiento de prueba es soportado por múltiples módulos, el sistema indica qué módulo es considerado más efectivo haciendo parpadear el icono resaltado. Cuando el usuario selecciona un icono resaltado, el sistema lanza la prueba apropiada o envía al usuario al correspondiente artículo en Llave de Almacén, si ese es el icono seleccionado.

El lanzamiento de un procedimiento de prueba particular incluirá típicamente la iniciación de una secuencia de representaciones en pantalla que dirigen al usuario en el comportamiento del procedimiento de prueba. Por ejemplo, si el módulo de Herramienta de Exploración está siendo implementado, el usuario será instruido en la manera de conectar y usar el lector asociado para descargar información desde el ordenador de a bordo del vehículo y/o controlar el funcionamiento de determinadas funciones del ordenador, todas de una manera conocida. Si, por otro lado, se selecciona el módulo de Analizador, las instrucciones para conducir el procedimiento seleccionado de prueba incluirá típicamente la conexión de los cables de prueba al vehículo asociado, condiciones deseadas de funcionamiento de motor y similares, todos de una manera conocida.

Los datos de diagnóstico iniciales para este sistema son recabados en primer lugar de los grupos de enfoque que contienen técnicos de OEM ya que su afiliación con un OEM particular les proporciona una exposición concentrada a aquellos vehículos y acceso aumentado a información de OEM. Sin embargo, su experiencia está limitada usualmente a vehículos de menos de tres años de antigüedad. Además de esto, sus datos tienden a reflejar los problemas que existen en la zona geográfica en la que viven los técnicos de OEM. Los datos recogidos en Florida pueden no reflejar exactamente los problemas existentes en un invierno de Minnesota. El diagnóstico del presente sistema debe cambiar durante la vida del vehículo para reflejar más precisamente los problemas que ocurren cuando el vehículo acumula kilometraje y para obtener una aplicación geográfica más amplia.

De acuerdo con esto, durante el diagnóstico del síntoma un icono (no mostrado) "Confirmar Diagnóstico" puede estar disponible en la pantalla. Cuando el usuario ha realizado un procedimiento de prueba seleccionado y ha encontrado la causa inicial para el síntoma o síntomas seleccionados, el usuario selecciona el icono Confirmar Diagnóstico. El sistema muestra entonces los síntomas que fueron seleccionados al comienzo del diagnóstico y la lista de pruebas recomendadas. El usuario puede elegir la prueba que encontró el problema y esos datos con guardados en una base de datos. En esa base de datos, el sistema almacena el vehículo actual, los síntomas seleccionados, el nombre de la prueba, y da a la prueba un contador de 1 por cada uno de los síntomas seleccionados. Si una prueba distinta de las pruebas recomendadas encuentra el problema, se presenta al usuario una caja de texto para introducir una breve descripción de la prueba usada para aislar la causa de los síntomas. Esos datos también son guardados. Los datos guardados son recuperados por medio de un módem durante un procedimiento de actualización de software. La verificación de datos y las rutinas de análisis presentarán los datos actualizados. Revisará el número de veces que cada prueba/causa diagnosticó cada síntoma para cada vehículo específico. Entonces comparará esta relación con las recomendaciones almacenadas en la base de datos y modificará el orden de clasificación según se necesite. Cada una de las reparaciones introducidas por usuario también serán revisadas para determinar si una nueva prueba debe ser desarrollada por el sistema o si la información debe ser añadida como un Consejo Rápido.

La figura 6 es un diagrama de flujo que ilustra el programa de software para el presente invento usando modos basados en fallos, tal como el modo de Prueba de Síntomas o el modo de Prueba de Código de Servicio. Primero, en 50, el usuario introduce información de identificación de vehículo usando una pantalla como la de la figura 2, y entonces selecciona el icono Prueba/Análisis, que mostrará una pantalla (véase la figura 3) que permitirá al usuario seleccionar el modo de funcionamiento Prueba de Síntoma, Prueba de Sistema o Componente o de Prueba de Código de Servicio. Cuando se selecciona el modo de Prueba de Síntoma o el modo de Prueba de Código de Servicio, el programa accede a la base de datos apropiada en 51 y muestra los fallos (síntomas o códigos de servicio) al usuario, como en la pantalla de la figura 3. El usuario selecciona uno o más fallos en 52, y entonces el sistema, en 53, accede a la base de datos con los fallos seleccionados y construye una lista de causas aplicables y procedimientos de prueba relacionados. Con relación a esto, el programa pregunta en 54 cuantos fallos se seleccionaron y, si uno fue seleccionado, ordena la lista en 55 por clasificación y la presenta al usuario, como en la pantalla de la figura 3, resaltando cualquier prueba que se haya realizado anteriormente en 56. Si, en 54, se ha seleccionado más de un fallo, el programa en 57 aplicaría un algoritmo de clasificación para cada causa/prueba y de nuevo ordenaría la lista, presentándola al usuario en forma de una pantalla tal como la de la figura 3. El usuario, entonces, en 58, selecciona la prueba a ser realizada, y el sistema en 59 engendra la prueba, incitando al usuario, según sea necesario, en su comportamiento. Entonces, el usuario indicará, usando un icono apropiado (no mostrado), si la prueba identificó o no la causa del fallo, por tanto a responder la pregunta del programa en 60. Si no lo hizo, el programa resalta esa prueba en la lista en 61 y el usuario selecciona entonces otra prueba. Si la prueba identifica el fallo, el programa en 62 almacena esa información para una recuperación posterior. El sistema interroga entonces en 63 si la prueba va de continuar. Si es así, la última prueba realizada es resaltada de nuevo en 61 y, si no, el sistema sale del modo de prueba de fallo en 64.

En el modo de Prueba de Código de Servicio, el funcionamiento es básicamente como se ha descrito antes, excepto porque el técnico usa los códigos de servicio del vehículo como el punto de inicio de diagnóstico, y los códigos de servicio son específicos a vehículo individuales. Cuando el usuario selecciona este modo, seleccionando el archivo 38 en la pantalla de la figura 3, el sistema permitirá dos métodos de inicio diferentes. En el primer método, el sistema incitará al usuario según sea necesario por medio de un procedimiento de acceso al código de servicio y utilizará el módulo de Herramienta de Exploración para leer los códigos de servicio existentes del vehículo. El sistema presenta entonces al usuario un menú solo de los códigos de servicio almacenados actualmente en la memoria del ordenador del vehículo. El usuario selecciona entonces el código que desea diagnosticar. En el segundo método, el técnico que ha recuperado previamente los códigos de servicio del vehículo. El sistema presenta entonces al usuario una presentación en pantalla que muestra un menú de todos códigos de servicio posibles en el vehículo que está siendo probado. El usuario selecciona el código que desea diagnosticar.

Basado en el código o códigos de servicio seleccionados, la pantalla de presentación muestra una lista de posibles causas de los códigos de servicio seleccionados y un lista equivalente de procedimientos de pruebas a realizar para comprobar esas causas, justo como en la figura 3, anterior. Los procedimientos de prueba son listados en orden de probabilidad o posibilidad que de la prueba sea exitosa para diagnosticar la causa del código de servicio seleccionado. La selección y puesta en marcha de un procedimiento de prueba mostrado se consigue de la misma manera descrita antes con relación al modo de Prueba de Síntoma de la figura 3.

El Modo de Prueba de Sistema, que puede ser introducido seleccionando el icono 37 del archivo Componente/Sistema en la pantalla 39 de la figura 3, verifica el funcionamiento de un subsistema del vehículo y usa en primer lugar pruebas de sistema de analizador de motor. En este modo de pruebas, el sistema no guía al técnico para determinar que pruebas deben realizarse. El técnico usa su propia experiencia para determinar qué pruebas son necesarias y el orden en el que deben ser realizadas. Muchas de estas pruebas son de procedimiento. Cada prueba contiene capacidad de recogida de datos y recordatorios. Cuando se completa la prueba un motor de diagnóstico evalúa los datos y presenta las conclusiones de diagnóstico.

El sistema presenta inicialmente, en la presentación de pantalla 65, al usuario un menú 66 de pruebas de sistema aplicables, como se ilustra en la figura 4. El técnico selecciona la prueba deseada del menú y el sistema resalta las aplicables de los iconos de módulo 44-48. El usuario selecciona un módulo resaltado y se pone en marcha una prueba asociada. Si el usuario vuelve a la pantalla de pruebas del sistema de la figura 4, cualquier prueba que haya sido completada anteriormente se mostrará de un color diferente. Esto proporciona un mecanismo para hacer seguimiento de qué pruebas han sido realizadas en esta sesión de diagnóstico. El sistema advierte al usuario durante el funcionamiento de cada prueba y recoge también los datos de la prueba y, cuando se completa la prueba, evalúa los datos y presenta al usuario las conclusiones de diagnóstico. Una vez que se ha completado la prueba, el sistema indicará este hecho, de manera que no se repita involuntariamente.

Si se selecciona el modo de Prueba de Componente, aparecerá la presentación en pantalla 67 de la figura 5. Las pruebas de componente verifican el funcionamiento de un solo componente del vehículo. En este modo de pruebas, el sistema no guía al técnico a determinar que pruebas deben realizarse. El técnico usa su propia experiencia para determinar que pruebas son necesarias y el orden en el que deberían realizarse.

La base de datos de pruebas de componentes contiene apuntadores a pruebas en la biblioteca de pruebas que se aplican al vehículo específico que está siendo probado. La lista de pruebas de componentes de vehículo disponible para el usuario es dinámica, ya que cada vehículo tiene potencialmente un único grupo de componentes. La biblioteca de pruebas de componentes puede contener cientos de pruebas de componente. La representación en pantalla 67 de la figura 5, lista las pruebas de componente disponibles para el vehículo que está siendo diagnosticado. El usuario selecciona la prueba de componente apropiada. El sistema remarcará los módulos aplicables usando los iconos 44-48 que soportan probar el componente seleccionado. El usuario selecciona un módulo remarcado para poner en marcha una prueba apropiada, esencialmente de la misma manera que como se ha descrito antes con relación al modo de diagnóstico basado en sistema.

De lo anterior se puede ver que se ha proporcionado un sistema de diagnóstico dinámico mejorado que acomoda varios métodos de diagnóstico diferentes, incluyendo diagnóstico basado en problema, y que es actualizado fácilmente para tener en cuenta la experiencia de servicio con el vehículo durante su vida útil.

Aunque se han mostrado y descrito realizaciones particulares del presente invento, será claro para los expertos en la técnica que se pueden hacer cambios y modificaciones sin apartarse del invento en sus aspectos más amplios. La materia expuesta en la descripción anterior y los dibujos que se acompañan se ofrecen sólo a modo de ilustración y no como una limitación.

Claims (11)

1. Un método para que un usuario diagnostique un aparato, en el que

- la información de identificación del aparato es introducida por el usuario (50) en un sistema de pruebas que comprende una base de datos remota

- como respuesta a una prueba que se está realizando para diagnosticar una causa de un fallo experimentado por el aparato, se comprueba si la prueba diagnosticó o no una causa del fallo (60); y

- si la prueba diagnosticó la causa del fallo, la información de identificación de aparato, el fallo o fallos seleccionados y el nombre de prueba, son almacenados (62); y

- estos datos almacenados son recogidos para actualizar la base de datos remota (62), caracterizado porque

- después de introducir la información de identificación de aparato, se presenta al usuario un menú de fallos (51);

- el usuario selecciona uno o más fallos (52);

- como respuesta a la selección del usuario de uno o más fallos en al menos una prueba es seleccionada de una base de datos remota, por lo que la prueba puede ser realizada en el aparato para diagnosticar la causa del fallo o fallos
(53, 54, 55, 57); y

- las pruebas están siendo listadas en el orden en el que sería más probablemente efectivo al diagnosticar los fallos (56), cuyo orden está basado en:

(a)

qué pruebas son necesarias para determinar la causa de los síntomas;

(b)

el orden en el que las pruebas deben ser realizadas basándose en la probabilidad de la causa; y

(c)

en el caso de que más de una causa tengan igual probabilidad, clasificar las recomendaciones de prueba por el tiempo necesario para realizar el procedimiento de prueba, clasificando más alto el tiempo más corto.

2. El método de la reivindicación 1, en el que el aparato comprende un vehículo.

3. El método de cualquiera de las reivindicaciones anteriores, en el que la representación de al menos una prueba al usuario para que el usuario seleccione comprende:

representar una indicación de al menos un sistema del aparato en el que una prueba puede ser realizada para diagnosticar una causa de un fallo que puede ser experimentado por el aparato.

4. El método de cualquiera de las reivindicaciones 1, 2, 3, en el que la representación de al menos una prueba al usuario para que el usuario seleccione comprende:

representar una indicación de al menos un componente del aparato en el que se puede realizar una prueba para diagnosticar una causa de un fallo que puede ser experimentado por el aparato.

5. El método de cualquiera de las reivindicaciones 1, 2, 3, en el que la representación de al menos una prueba al usuario comprende acceder a una base de datos de conocimiento que incluye una biblioteca que comprende una pluralidad de pruebas (53).

6. El método de cualquiera de las reivindicaciones 1, 2, 3, en el que la representación de al menos una prueba al usuario comprende indicar qué pruebas han sido realizadas anteriormente.

7. El método de la reivindicación 1, en el que la recepción de información de identificación de aparato comprende:

solicitar al usuario que realice un procedimiento de identificación de aparato.

8. El método de la reivindicación 1, que comprende además:

solicitar al usuario que realice la prueba.

9. El método de la reivindicación 1, que comprende además:

almacenar datos de pruebas en un mecanismo de almacenamiento de datos.

10. El método de la reivindicación 1, en el que la biblioteca del sistema remoto actualiza los datos de diagnóstico del aparato.

11. El método de la reivindicación 1, que comprende además:

evaluar los datos de prueba y representar al menos una conclusión de diagnóstico al usuario.