BR112013020413B1 - método e dispositivo de cliente que realiza tal método - Google Patents

Abstract

LINHA DE BASE DE DIAGNÓSTICO Métodos e dispositivos relacionados ao diagnóstico de um dispositivo em serviço (DUS) são expostos. Dado relacionado ao DUS é recebido. O dado relacionado ao DUS é determinado para ser agregado em dado agregado com base em uma determinada classificação do dado relacionado ao DUS. Uma comparação de dado agregado do dado relacionado ao DUS e dados agregados é gerada. A comparação de dado agregado pode incluir a análise estatística do dado relacionado ao DUS e/ou uma análise diferencial de dado relacionado ao DUS tomadas enquanto o DUS está operando em dois ou mais estados de operação. Um realatório de DUS é gerado com base na comparação de dado agregado. O relatório de DUS pode incluir uma ou mais sub-estratégias. Pelo menos uma das uma ou mais sub-estratégias pode incluir uma estimativa de sucesso de sub-estratégia. O relatório de DUS pode ser enviado e uma exibição de relatório de DUS pode ser gerada com base no relatório de DUS.

Description

PEDIDOS RELACIONADOS

[0001] O presente pedido reivindica a prioridade do Pedido de Patente US n.° 13/031.565, intitulado “Linha de Base de Diagnóstico”, depositado em 21 de fevereiro de 2011, que é incorporado inteiramente para referência para todas as finalidades.

ANTECEDENTES

[0002] Veículos, tais como automóveis, caminhões leves, e caminhões pesados, desempenham um papel importante nas vidas de muitas pessoas. Para manter os veículos operacionais, algumas dessas pessoas contam com técnicos para diagnosticar e reparar seu veículo.

[0003] Técnicos de veículo usam uma variedade de ferramentas a fim de diagnosticar e/ou reparar veículos. Aquelas ferramentas podem incluir ferramentas manuais comuns, tais como chaves de boca, martelos, alicates, chaves de fenda e jogos de chaves, ou mais ferramentas específicas de veículos, tais esmeris cilíndricos, compressores de anel de pistão, e ferramentas de freio de veículo. As ferramentas usadas por técnicos de veículo podem também incluir ferramentas eletrônicas, tais como uma ferramenta de varredura de veículo ou um medidor de voltagem-ohm digital (DVOM), para uso no diagnóstico e/ou reparo de um veículo.

[0004] A ferramenta de varredura de veículo e/ou o DVOM podem ser ligados através de ligação(ões) com fio e/ou sem fio a outros dispositivos, possivelmente para comunicar dados acerca do veículo. A ferramenta de varredura de veículo e/ou DVOM pode fornecer uma quantidade significante de dados para ajudar o diagnóstico e reparo do veículo. Tipicamente, o dado não inclui dado contextual, tal como relatório de histórico. Ainda, o dado é tipicamente formatado de modo que a interpretação de dado por pessoal especializado, tal como um técnico de veículo, é requerida antes de um problema com o veículo poder ser identificado, diagnosticado e/ou reparado.

VISÃO GERAL

[0005] Várias modalidades de exemplo são descritas nesta descrição. Em um aspecto, uma modalidade de exemplo pode assumir a forma de um método. Em um dispositivo de servidor, dado relacionado a dispositivo em serviço (DUS) é recebido para um DUS. O dado relacionado ao DUS é determinado para ser agregado em dado agregado no dispositivo de servidor. A determinação que o dado relacionado ao DUS deve ser agregado é baseada em uma classificação do dado relacionado ao DUS. Uma comparação de dado agregado do dado relacionado ao DUS e do dado agregado é gerado no dispositivo de servidor. Um relatório de DUS baseada na comparação de dado agregado é então gerado no dispositivo de servidor. O relatório de DUS inclui uma ou mais sub-estratégias. Pelo menos uma das uma ou mais sub- estratégias inclui uma estimativa de sucesso de sub-estratégia. O relatório de DUS é então enviado pelo dispositivo de servidor.

[0006] Em um segundo aspecto, uma modalidade de exemplo pode assumir a forma de um dispositivo de cliente que inclui uma memória, um processador, e instruções. As instruções são armazenadas na memória. Em resposta à execução pelo processador, as instruções fazem com que o dispositivo de cliente execute funções. As funções podem incluir: (a) receber um pedido de diagnóstico para um DUS, (b) enviar, para o DUS, um pedido de teste de DUS para realizar um teste relacionado ao pedido de diagnóstico, (c) receber, a partir do DUS, dado relacionado ao DUS, (d) enviar o dado relacionado ao DUS, (e) receber um relatório de DUS com base nenhum dado relacionado ao DUS, e (f) gerar uma exibição de relatório de DUS do relatório de DUS.

[0007] Em um terceiro aspecto, uma modalidade de exemplo pode assumir a forma de um método. Um dispositivo recebe um pedido de diagnóstico para diagnosticar um DUS. Um teste baseado no pedido de diagnóstico é determinado no dispositivo. O teste é relacionado a um primeiro estado de operação do DUS. O dispositivo solicita o desempenho do teste no primeiro estado de operação do DUS. Dado do primeiro estado de operação para o DUS é recebido no dispositivo. O dado do primeiro estado de operação é baseado no teste. O desempenho do teste no segundo estado de operação do DUS é solicitado pelo dispositivo de cliente.

[0008] O dispositivo verifica que o dado do primeiro estado de operação é ou não é relacionado ao primeiro estado de operação. Em resposta à verificação que o dado do primeiro estado de operação é relacionado ao primeiro estado de operação, o dispositivo (a) gera uma análise diferencial baseada no dado do primeiro estado de operação, (b) gera uma exibição de relatório de DUS com base na análise diferencial, e (c) envia a exibição de relatório de DUS.

[0009] Esses bem como outros aspectos e vantagens ficarão aparentes para aqueles de conhecimento comum na arte pela leitura da seguinte descrição detalhada, com referência, onde apropriado, aos desenhos anexos. Ainda, deve ser entendido que as modalidades descritas nesta visão geral e em outros lugares são destinadas a serem somente exemplos e não limitam necessariamente o escopo da invenção.

BREVE DESCRIÇÃO DOS DESENHOS

[00010] Modalidades de exemplo são descritas aqui com referência aos desenhos, em que os mesmos números denotam os mesmos componentes, nos quais:

[00011] a Figura 1 é um diagrama em blocos de um sistema de exemplo;

[00012] a Figura 2 é um diagrama em blocos de um dispositivo de computação de exemplo;

[00013] a Figura 3 é um diagrama em blocos de um dispositivo de cliente de exemplo;

[00014] a Figura 4 é um diagrama em blocos de um dispositivo de servidor de exemplo;

[00015] a Figura 5 representa uma exibição de coleta de dado de exemplo;

[00016] a Figura 6A mostra um cenário de exemplo para processar um pedido de diagnóstico, gerando responsivamente uma exibição de relatório de DUS, e recebendo dado relacionado ao sucesso;

[00017] a Figura 6B mostra um cenário de exemplo para processar dado relacionado ao DUS e gerando responsivamente um pedido de diagnóstico;

[00018] a Figura 6C mostra um cenário de exemplo para processar dado relacionado ao DUS e gerando responsivamente um relatório de DUS;

[00019] a Figura 6D mostra outro cenário de exemplo para processar dado relacionado ao DUS e gerando responsivamente um relatório de DUS;

[00020] a Figura 7A mostra um cenário de exemplo para processar um pedido de diagnóstico, gerando responsivamente uma exibição de relatório de DUS, e recebendo dado relacionado ao sucesso;

[00021] a Figura 7B mostra um cenário de exemplo para processar um pedido de diagnóstico e gerando responsivamente um pedido de teste de DUS;

[00022] a Figura 7C mostra um cenário de exemplo para processar dado relacionado ao DUS e gerando responsivamente uma exibição de relatório de DUS;

[00023] a Figura 8A representa um fluxograma de exemplo que ilustra funções para gerar uma análise diferencial;

[00024] a Figura 8B mostra uma grade de exemplo com uma célula de grade que corresponde a um primeiro estado de operação e uma célula de grade que corresponde a um segundo estado de operação;

[00025] a Figura 9 representa um fluxograma de exemplo que ilustra funções que podem ser executadas de acordo com uma modalidade de exemplo;

[00026] a Figura 10 é outro fluxograma representando funções que podem ser executadas de acordo com uma modalidade de exemplo; e

[00027] a Figura 11 é ainda outro fluxograma representando funções que podem ser executadas de acordo com uma modalidade de exemplo.

DESCRIÇÃO DETALHADA INTRODUÇÃO

[00028] Esta descrição expõe sistemas compreendendo múltiplos dispositivos. Cada dispositivo de um sistema descrito é operável independentemente (por exemplo, como um dispositivo autônomo) bem como em combinação com outros dispositivos do sistema. Cada dispositivo de um sistema descrito pode ser referido como um aparelho.

[00029] Cada dispositivo de um sistema descrito é operável para executar funções para manutenção de um DUS (DUS). O DUS pode compreender um veículo, uma unidade de refrigeração, um computador pessoal, ou algum outro dispositivo no qual manutenção pode ser feita. Adicionalmente ou alternativamente, o DUS pode compreender um sistema, tal como um sistema de aquecimento, ventilação, e de condicionamento de ar (HVAC), um sistema de segurança, um sistema de computador (por exemplo, uma rede), ou algum outro sistema no qual manutenção pode ser feita. As funções para manutenção do DUS podem incluir, mas não são limitadas a, funções de diagnóstico, funções de medição, e funções de varredura.

[00030] Para trabalhar em combinação um com o outro, o dispositivo de um sistema descrito é configurado para se comunicar com outro dispositivo através de uma rede de comunicações. A rede de comunicações pode compreender uma rede sem fio, uma rede com fio, ou com ambas, uma rede sem fio e uma rede com fio. Dado obtido por um dispositivo a partir do DUS ou dado contido de outra maneira neste o dispositivo pode ser transmitido para outro dispositivo através da rede de comunicações entre aqueles dispositivos.

[00031] Dispositivos no sistema descrito podem ser conectados através de conexões com fio e/ou sem fio. Conexões com fio e sem fio pode utilizar um ou mais protocolos de comunicação arranjados de acordo com uma ou mais normas, tais como uma da SAE Internacional, Organização Internacional de Normalização (ISO), ou a norma 802 do Instituto dos Engenheiros de Eletricidade e de Eletrônica (IEEE). A conexão com fio pode ser estabelecida usando um ou mais protocolos de comunicação com fio, tais como da série de protocolos Diagnóstico A Bordo II (“OBD-II”) (por exemplo, SAE J1850, SAE J2284, ISO 9141-2, ISO 14230, ISO 15765), 802.3 do IEEE (“Ethernet”), ou 802.5 do IEEE (“Token Ring”). A conexão sem fio pode ser estabelecida usando um ou mais protocolos de comunicação sem fio, tais como Bluetooth, IEEE 802.11 (“Wi-Fi”), ou IEEE 802.16 (“WiMax”).

[00032] Um dispositivo de cliente do sistema descrito é configurado para se comunicar diretamente com o DUS; em parte por enviar pedidos de teste para informação de diagnóstico e receber dados relacionados ao teste em resposta. Em algumas modalidades, os pedidos de teste e/ou dados relativos ao teste são formatados de acordo com um protocolo OBD-II.

[00033] O dispositivo de cliente pode solicitar a operação do DUS em uma variedade de condições de operação para coletar os dados relativos ao teste. As condições e quantidade de dados coletados podem ser personalizados com base em um tipo de usuário (por exemplo, técnico de serviço, pessoa leiga, engenheiro, etc.) usando dispositivo de cliente. O dispositivo de cliente pode também coletar uma “reclamação” acerca do DUS, que pode incluir texto sobre a condição de operação do DUS. Em algumas modalidades, a reclamação pode ser especificada como um “código de reclamação”, tal como um código alfanumérico.

[00034] Um dispositivo de servidor do sistema descrito é configurado para receber o dado relacionado ao teste e possivelmente “dado relacionado a dispositivo” para o DUS e gerar responsivamente um “relatório de DUS”. O relatório de DUS pode incluir uma “estratégia” para diagnosticar e/ou reparar o DUS para abordar uma reclamação. A estratégia pode incluir uma “análise estatística” do dado relacionado ao teste recebido e/ou uma ou mais “sub-estratégias” (por exemplo, recomendações, direções, ações propostas, e/ou testes adicionais). O dado relacionado a dispositivo pode incluir, mas não é limitado a dado para montador do dispositivo, identidade do fabricante do dispositivo, modelo do dispositivo, tempo de fabricação do dispositivo (por exemplo, ano do modelo), milhagem, relatório da unidade de controle do dispositivo (por exemplo, para um veículo, tipo da unidade de controle do motor (ECU) e informação de lançamento), os dados do tempo de operação, informação de identidade do dispositivo, informação de identidade do proprietário do dispositivo, provedor de serviços, local dos serviços, técnico de serviço, e/ou local do dispositivo. Em algumas modalidades, o dispositivo de cliente pode gerar o relatório de DUS.

[00035] O dispositivo de servidor e/ou o dispositivo de cliente pode criar um “perfil” para o DUS. O perfil pode ser configurado para armazenar o dado relacionado ao dispositivo referente ao DUS, a reclamações, relatórios de DUS, e/ou dados relacionados ao teste tomados em vários momentos durante a vida útil do DUS.

[00036] Em algumas modalidades, “pontos de referência” ou “dados de referência” são armazenados, possivelmente com o perfil. Os dados de referência podem ser tomados durante um intervalo de operação sem reclamações do DUS. Dados de referência podem incluir dados fornecidos por um fabricante de equipamento original (OEM) com respeito à operação ideal/recomendada.

[00037] Em algumas modalidades, um “registrador de dados” pode ser instalado no DUS para coletar os dados de referência. Nessas modalidades, uma vez quando dado de referência é coletado, o dado de referência pode ser comunicado a partir do registrador de dados para um “fornecedor de serviços” responsável pelo diagnóstico, manutenção, e/ou reparo do DUS. Em outras modalidades, o fornecedor de serviços coleta os dados de linha de base em um instalação de serviço.

[00038] O dado de referência pode ser comparado com dado relacionado ao teste tomado em resposta a uma reclamação acerca do DUS. Ainda, dado de referência e/ou dado relacionado ao teste a partir de um número dos dispositivos em serviço podem ser combinados e/ou agregados em um conjunto de “dados agregados”. O processo de agregação pode incluir determinar uma classificação e/ou confiabilidade para o dado agregado.

[00039] Dado relacionado ao teste pode ser “classificado” antes de ser adicionado ao dado agregado. Classificações de exemplo de dados agregados podem incluir uma classificação de dado de referência e uma ou mais classificações de diagnóstico. Por exemplo, se o DUS está operando sem reclamação, dado relacionado ao teste, obtido a partir do DUS, pode ser classificado como dado de referência na agregação ao dado agregado. Todavia, se o DUS está operando com uma falha no sistema de frenagem, dado relacionado ao teste proveniente do DUS pode ser classificado como dado de “freio defeituoso” na agregação ao dado agregado. Muitos outros tipos de classificações são também possíveis.

[00040] Dado de referência para um DUS e possivelmente outro dado pode usado na geração de “dado de linha de base” para um DUS. Os dados de linha de base podem incluir um resumo estatístico sobre os dados tomados para os dispositivos que compartilham “informação de núcleo-dispositivo” (por exemplo, ano, modelo, marca, e/ou tipo de ECU/informação de lançamento). Os dados de linha de base podem chegar agregados e/ou atualizados ao longo do tempo. Por exemplo, quanto mais dado relacionado ao teste é agregado para os dispositivos em serviço que compartilham informação de núcleo-dispositivo, os dados de linha de base podem ter valores de confiança e/ou intervalos mais altos para dados agregados de linha de base sobre o tempo.

[00041] Outros dados diferentes dos dados de linha de base que compartilham uma classificação comum podem ser também agregados. Por exemplo, o dado de “freio defeituoso” pode chegar agregado e, quanto mais dado de freio defeituoso é agregado ao longo do tempo, os dados de freio defeituoso dados podem ter valores de confiança e/ou intervalos crescentemente mais altos para dados agregados de freio defeituoso ao longo do tempo. Agregação de dados para outras classificações é também possível.

[00042] O relatório de DUS pode ser gerado com base em uma comparação dos dados relacionados ao teste e dados agregados. Por exemplo, o dispositivo de servidor pode armazenar dados agregados, possivelmente incluindo core-dispositivo relatório e/ou dado de linha de base para o DUS. Na recepção dos dados relacionados ao teste e uma reclamação, o dispositivo de servidor pode determinar um subconjunto dos dados agregados com base nos dados relacionados a dispositivo para o DUS. Então, os dados relacionados ao teste e o subconjunto determinado de dados agregados podem ser comparados para determinar a análise estatística, incluindo um número de estatísticas para o dado relacionado ao teste, para o relatório de DUS.

[00043] Em algumas modalidades, a análise estatística pode ser gerada com base em uma “análise diferencial” ou comparação do DUS operado em um ou mais “estados de operação”. Estados de operação de exemplo para um motor de um veículo (atuando como um DUS) incluem estados de operação sem carga/ligeiramente carregado (por exemplo, um estado de operação “de marcha lenta”), vários estados de operação sob cargas normais (por exemplo, um estado de operação de “cruzeiro”, um estado de operação de “arranque”), e estados de operação na, ou perto da, carga máxima (por exemplo, um estado de operação de “alta velocidade”). Outros estados de operação são também possíveis. Então, a análise estatística pode ser determinada com base em diferenças no dado relacionado ao teste quando DUS operado no estado de operação em dois ou mais instantes diferentes e/ou entre duas ou mais diferentes medições.

[00044] Um “motor de regras” pode tomar a análise estatística e relatório sobre a reclamação, avaliar a análise estatística à luz de uma ou mais regras acerca do DUS e os dados de reclamação, e fornecer uma estratégia para investigar a reclamação. Em algumas modalidades, o motor de regras pode incluir um motor de inferência, tal como um sistema especialista ou sistema de resolução de problemas, com uma base de conhecimentos que se relaciona com pelo menos a avaliação, diagnóstico, operação, e/ou reparo do DUS.

[00045] O motor de regras pode gerar o relatório de DUS, possivelmente por combinação da análise estatística e da estratégia para abordar a reclamação. O dispositivo de cliente e/ou o dispositivo de servidor pode incluir o motor de regras. Em algumas modalidades, o motor de regras do dispositivo de cliente difere do motor de regras do dispositivo de servidor.

[00046] O relatório de DUS pode ser exibido, possivelmente no dispositivo de cliente, possivelmente para permitir a realização de uma estratégia do relatório de DUS. Feedback relacionado a sub-estratégias da estratégia pode ser fornecida e usada para ajustar uma “estimativa de sucesso de sub-estratégia” ou probabilidade de que a sub-estratégia pode abordar um problema mencionado nos dados de reclamação. Tais estimativas de sucesso de sub-estratégia podem ser fornecidas com o relatório de DUS.

[00047] Pela realização de análises estatísticas dos dados agregados (incluindo dados de linha de base) dados relacionados ao teste, este sistema pode avaliar os dados relacionados ao teste no contexto de uma maior população de dados. Por comparação dos dados relacionados ao teste com os dados agregados classificados e/ou dados de linha de base, quaisquer discrepâncias entre os dados agregados classificados e/ou dado de linha de base e os dados relacionados ao teste, como mostrados na análise estatística, podem ser mais facilmente identificadas e assim o diagnóstico de velocidade e reparo do DUS. Por meio a realização de análises diferenciais usando um procedimento de teste de operar meramente um DUS em um estado de operação e/ou em dois (ou mais) momentos/fontes diferentes (por exemplo, os dados agregados/linha de base e dados relacionados ao teste), os procedimentos de diagnóstico iniciais podem ser simplificados. Uma estratégia fornecida com o relatório de DUS pode incluir sub- estratégias para diagnóstico e/ou reparo do DUS, reduzindo ainda mais o tempo para o reparo. Por meio da provisão da análise estatística e/ou análise diferencial com base em uma população de dados, juntamente com uma estratégia para diagnóstico e reparo, o relatório do dispositivo em reparo reduz grandemente, se não elimina, conjecturas acerca do dado relacionado ao teste, e reduz o tempo de inatividade para o dispositivo em reparo.

II. ARQUITETURA DE EXEMPLO

[00048] A Figura 1 é um diagrama em blocos de um sistema de exemplo 100. O sistema 100 compreende um dispositivo em serviço (DUS) 102 e os dispositivos 104 e 106. Para finalidades desta descrição, o dispositivo 104 é referido como um dispositivo de cliente e o dispositivo 106 é referido como um dispositivo de servidor.

[00049] O diagrama em blocos da Figura 1 e outros diagramas e fluxogramas que acompanham esta descrição são fornecidos meramente como exemplos e não são destinados a serem limitativos. Muitos dos elementos ilustrados nas figuras e/ou descritos aqui são elementos funcionais que podem ser implementados como componentes discretos ou distribuídos ou em conjunção com outros componentes, e em qualquer combinação apropriada e locais. Aqueles especializados na arte apreciarão que outros arranjos e elementos (por exemplo, máquinas, interfaces, funções, ordens, e agrupamentos de funções, etc.) podem ser, entretanto, usados. Em particular, algumas ou todas das funcionalidades descritas aqui como funcionalidade de dispositivo de cliente (e/ou funcionalidade de componentes de um dispositivo de cliente) podem ser implementadas por um dispositivo de servidor, e algumas ou todas das funcionalidades descritas aqui como funcionalidade de dispositivo de servidor (e/ou funcionalidade de componentes de um dispositivo de servidor) podem ser implementadas por um dispositivo de cliente.

[00050] Além disso, várias funções, técnicas, e funcionalidades descritas aqui como sendo realizadas por um ou mais elementos podem ser realizadas por um processador que executa instruções de programa legíveis por computador e/ou por qualquer combinação de hardware, firmware e software.

[00051] O DUS 102 pode compreender um veículo, tal como um automóvel, uma motocicleta, um semi-trator, máquina agrícola, ou algum outro veículo. O sistema 100 é operável para executar uma variedade de funções, incluindo funções para manutenção de DUS 102. As modalidades de exemplo podem incluir ou ser utilizadas com qualquer apropriada fonte de voltagem ou corrente, tal como uma bateria, um alternador, uma célula de combustível, e similar, fornecendo qualquer corrente e/ou voltagem apropriada, tal como cerca de 12 volts, cerca de 42 volts, e similares. As modalidades de exemplo podem ser usadas com qualquer sistema ou motor desejado. Aqueles sistemas ou motores podem compreender itens que utilizam combustíveis fósseis, tais como gasolina, gás natural, propano, e similar, eletricidade, tal como aquela gerada por bateria, magneto, célula de combustível, célula solar e similar, vento e híbridos ou combinações dos mesmos. Aqueles sistemas ou motores podem ser incorporados em outros sistemas, tais como um automóvel, um caminhão, um bote ou navio, uma motocicleta, um gerador, uma aeronave e similar.

[00052] O dispositivo de cliente 104 e/ou dispositivo de servidor 106 podem ser dispositivos de computação, tais como dispositivo de computação de exemplo 200 descrito abaixo no contexto da Figura 2. Em algumas modalidades, o dispositivo de cliente 104 compreende a digital volt meter (DVM), a digital volt ohm meter (DVOM), e/ou algum outro tipo de dispositivo de medição.

[00053] A rede 110 pode ser estabelecida para ligar comunicativamente os dispositivos 104 e 106. Qualquer um desses dispositivos pode se comunicar através de uma rede 110, uma vez quando dispositivo estabelece uma conexão ou ligação com a rede 110. Como um exemplo, a Figura 1 mostra a rede 110 conectada a:  dispositivo de cliente 104 através da ligação 114 e o dispositivo 106 conectado através da ligação 116. Em modalidades não mostradas na figura 1, DUS 102 pode também ser conectado à rede 110.

[00054] A rede 110 pode incluir e/ou conectar-se a uma rede de dados, tal como uma rede de área larga (WAN), uma rede de área local (LAN), uma ou mais redes de comunicação pública, tal como a Internet, uma ou mais redes de comunicação privada, ou qualquer combinação de tais redes. A rede 110 pode incluir ligações com fio e/ou sem fio e/ou dispositivos que utilizam um ou mais protocolos de comunicação arranjados de acordo com uma ou mais normas, tal como uma da SAE Internacional, Organização Internacional de Normalização (ISO), ou Norma do Instituto dos Engenheiros de Eletricidade e de Eletrônica (IEEE).

[00055] A rede 110 pode ser arranjada para executar comunicações de acordo com um respectivo protocolo de ar-interface. Cada protocolo de ar-interface pode ser arranjado de acordo com uma norma da indústria, tal como uma norma 802 do Instituto dos Engenheiros de Eletricidade e de Eletrônica (IEEE). A norma do IEEE 802 pode compreender uma norma do IEEE 802.11 para redes de Área Local Sem Fio (por exemplo, IEEE 802.11 a, b, g ou n), uma norma do IEEE 802.15 para Redes de Área Pessoal Sem Fio, uma norma 802.15.1 do IEEE para Redes de Área Pessoal Sem Fio - Grupo de Tarefa 1, uma norma 802.15.4 do IEEE para Redes de Área Pessoal Sem Fio - Grupo de Tarefa 4, uma norma 802.16 do IEEE para Redes de Área Metropolitana Sem Fio de Banda Larga, ou alguma outra norma do IEEE 802. Para finalidades desta descrição, uma rede sem fio (ou ligação) arranjada para executar comunicações de acordo com uma norma do IEEE 802.11 é referida como uma rede de Wi-Fi (ou ligação), uma rede sem fio (ou ligação) arranjada para executar comunicações de acordo com uma norma 802.15.1 do IEEE é referida como uma rede (ou ligação) Bluetooth, uma rede sem fio (ou ligação) arranjada para executar comunicações de acordo com uma norma 802.15.4 do IEEE é referida como uma rede (ou ligação) de Zigbee, e uma rede sem fio (ou ligação) arranjada para executar comunicações de acordo com uma norma 802.16 da IEEE é referida como uma rede (ou ligação) de Wi-Max.

[00056] A rede 110 pode ser arranjada para executar comunicações de acordo com um protocolo de comunicação com fio. Cada protocolo de comunicação com fio pode ser arranjado de acordo com uma norma da indústria, tal como 802.3 do IEEE (“Ethernet”) ou 802.5 do IEEE (“Token Ring”). Para finalidades desta descrição, uma rede com fio (ou ligação) arranjada para executar comunicações de acordo com um protocolo OBD-II é referida como uma rede (ou ligação) de OBD-II, uma rede com fio (ou ligação) arranjada para executar comunicações de acordo com uma norma 802.3 do IEEE é referida como uma rede (ou ligação) de Ethernet, e uma rede com fio (ou ligação) arranjada para executar comunicações de acordo com uma norma 802.5 do IEEE é referida como uma rede (ou ligação) de Token Ring.

[00057] Como tais, a ligações sem fio à rede 110 podem ser estabelecidas usando um ou mais protocolos de comunicação de interface de ar sem fio, tais como, mas não limitados a, Bluetooth, Wi-Fi, Zigbee e/ou WiMax. Similarmente, ligações com fio à rede 110 podem ser estabelecidas usando um ou mais protocolos de comunicação com fio, tais como, mas não limitados a, Ethernet e/ou Token Ring. Como tais, as ligações 114 e 116 podem ser ligações com fio e/ou sem fio à rede 110. Ligações adicionais e/ou protocolos com fio e/ou sem fio agora conhecidos ou posteriormente desenvolvidos podem ser usados também na rede 110.

[00058] Em algumas modalidades não mostradas na Figura 1, a ligações com fio e/ou sem fio, ponto a ponto, podem ser estabelecidas entre o dispositivo de cliente 104 e dispositivo de servidor 106. Em tais modalidades, uma funcionalidade aqui descrita da rede 110 pode ser realizada por essas ligações ponto a ponto. Em outras modalidades não mostradas na Figura 1, os dispositivos adicionais não mostrados na Figura 1 (por exemplo, o dispositivo de computação, telefone inteligente, assistente digital pessoal, telefone, etc.), podem se comunicar com o DUS 102, o dispositivo de cliente 104, o dispositivo de servidor 106, e/ou outros dispositivos através da rede 110. O dispositivo de cliente 104 e/ou dispositivo de servidor 106 podem operar para comunicar os aqui descritos dados, relatórios, pedidos, consultas, perfis, exibições, análises, e/ou outros dados (por exemplo, os dados de reparo de automóvel e/ou dados de instrução) para um ou mais desses  dispositivos adicionais não mostrados na Figura 1.

[00059] O dispositivo de cliente 104 pode conectar-se ao DUS 102 através da ligação 112. Em algumas modalidades, a ligação 112 é uma conexão com fio ao DUS 102, possivelmente uma ligação de OBD-II ou Ligação de Ethernet. Em outras modalidades, a ligação 112 é uma ligação sem fio. Em algumas dessas modalidades, a ligação sem fio é configurada para transportar pelo menos dados formatados de acordo com um protocolo OBD-II. Por exemplo, um “varredor de OBD-II” pode ser utilizado para transportar dados de OBD-II através de uma ligação sem fio. O varredor de OBD-II é um dispositivo com uma ligação de OBD-II com fio ao DUS 102 e um transmissor sem fio. O varredor de OBD-II pode recuperar dados formatados de acordo com um protocolo OBD-II a partir do DUS 102 e transmitir os dados formatados de OBD-II através de uma ligação sem fio (por exemplo, uma ligação de Bluetooth, Wi-Fi, ou Zigbee) estabelecida usando transmissor sem fio. Um varredor de OBD-II, de exemplo, é o Módulo Varredor Sem Fio VERDICT S3 fabricado por Snap-on Incorporated of Kenosha, WI. Em algumas modalidades, protocolos diferentes de um protocolo OBD-II, agora conhecidos ou posteriormente desenvolvidos, podem ser formatos de dado e/ou transmissão específicos.

[00060] Em outro exemplo, um registrador de dados (não mostrado na Figura 1) pode ser usado para coletar dados a partir do DUS 102 durante a operação. Uma vez quando a ligação 112 ao DUS 102 é conectada, o registrador de dados pode comunicar os dados coletados ao dispositivo de cliente 104 e possivelmente ao dispositivo de servidor 106.

[00061] A Figura 2 é um diagrama em blocos de um dispositivo de computação de exemplo 200. Como ilustrado na Figura 2, o dispositivo de computação 200 inclui uma interface de usuário 210, uma interface de rede de comunicação 212, um processador 214, e armazenamento de dados 216, todos dos quais podem ser ligados conjuntamente através de uma barra coletora de sistema, rede, ou outro mecanismo de conexão 220.

[00062] A interface de usuário 210 é operável para apresentar dados para e/ou receber dados a partir de um usuário do dispositivo de computação 200. A interface de usuário 200 pode incluir unidade de entrada 230 e/ou unidade de saída 232. A unidade de entrada 230 pode receber entrada, possivelmente a partir de um usuário do dispositivo de computação 200. A unidade de entrada 230 pode compreender um teclado, um “keypad”, uma tela de toque, um mouse de computador, uma esfera de controle, um “joystick”, e/ou outros dispositivos similares, agora conhecidos ou desenvolvidos posteriormente, capazes de receber entrada no dispositivo de computação 200.

[00063] A unidade de saída 232 pode fornecer saída, possivelmente para um usuário do dispositivo de computação 200. A unidade de saída 232 pode compreender um dispositivo de saída visível para gerar saída(s) visual(is), tais como uma ou mais tubos de raios catódicos (CRT), visores de cristal líquido (LCD), díodos de emissão de luz (LEDs), os visores usando digital tecnologia de processamento de luz (DLP), impressoras, bulbos de luz, e/ou outros dispositivos similares, agora conhecidos ou desenvolvidos posteriormente, capazes de exibir informação gráfica, textual, e/ou numérica. A unidade de saída 232 pode, alternativamente ou adicionalmente, compreender um ou mais dispositivos de saída auditivos para gerar saída(s) audível(is), tais como um alto-falante, tomada de alto-falante, porta de saída de áudio, o dispositivo de saída de áudio, fones de ouvido, e/ou outros dispositivos similares, agora conhecidos ou desenvolvidos posteriormente, capazes de transportar informação sonora e/ou audível.

[00064] A interface de rede de comunicação 212 pode incluir interface sem fio 240 e/ou interface com fio 242, possivelmente para comunicação através da rede 110 e/ou através de ligação(ões) de ponto a ponto. A interface sem fio 240 pode incluir um transceptor de Bluetooth, um transceptor de Zigbee, um transceptor de Wi-Fi, um transceptor de WiMAX, e/ou algum outro tipo de transceptor sem fio. A interface sem fio 240 pode realizar comunicações com os dispositivos 102, 104, 106, rede 110, e/ou outro(s) dispositivo(s) configurado(s) para se comunicar sem fio.

[00065] A interface com fio 242 pode ser configurada para se comunicar de acordo com um protocolo de comunicação com fio (por exemplo, Ethernet, Token Ring de OBD-II) com os dispositivos 102, 104, e/ou 106, rede 110, e/ou outro(s) dispositivo(s) configurado(s) para se comunicar através de ligações com fio. A interface com fio 242 pode compreender uma porta, um fio metálico, um cabo, uma ligação por fibra óptica ou uma conexão física similar aos dispositivos 102, 104, 106, rede 110, e/ou outro(s) dispositivo(s) configurado(s) para se comunicar através de fio metálico.

[00066] Em algumas modalidades, a interface com fio 242 compreende uma porta de Universal Serial Bus (USB). A porta USB pode se conectar comunicativamente a uma primeira extremidade de um cabo USB, enquanto uma segunda extremidade do cabo USB pode se conectar comunicativamente a uma porta USB de outro dispositivo conectado à rede 110 ou a algum outro dispositivo. Em outras modalidades, a interface com fio 242 compreende uma porta de Ethernet. A porta de Ethernet pode se conectar comunicativamente a uma primeira extremidade de um cabo de Ethernet, enquanto uma segunda extremidade do cabo de Ethernet pode se conectar comunicativamente a uma porta de Ethernet de outro dispositivo conectado à rede 110 ou a algum outro dispositivo.

[00067] Em algumas modalidades, a interface de rede de comunicação 212 pode fornecer comunicações confiáveis, seguras, e/ou autenticadas. Para cada comunicação descrita aqui, relatório para assegurar comunicações confiáveis (isto é, emissão de mensagem garantida) pode ser fornecido, possivelmente como parte de um cabeçalho de mensagem e/ou rodapé (por exemplo, informação de sequenciação de pacote/mensagem, cabeçalho(s) e/ou rodapé(s) de encapsularão, informação de tamanho/horário, e relatório de verificação de transmissão, tal como verificação de redundância cíclica (CRC) e/ou valores de verificação de paridade). As comunicações podem ser tornadas seguras (por exemplo, ser codificadas ou cifradas) e/ou decifradas/decodificadas usando um ou mais protocolos de cifragem e/ou algoritmos, tais como, mas não limitados a, DES, AES, RSA, Diffie-Hellman e/ou DSA. Outros protocolos e/ou algoritmos criptográficos podem ser também usados ou em adição àqueles listados aqui, para proteger as (e então decifrar/descodificar) comunicações.

[00068] O processador 214 pode compreender uma ou mais processadores de finalidades gerais (por exemplo, microprocessadores fabricados por Intel ou Advanced Micros Devices) e/ou um ou mais processadores de finalidades especiais (por exemplo, processadores de sinais digitais). O processador 214 pode executar instruções de programa legíveis por computador 250 que estão contidas no armazenamento de dados 216 e/ou outras instruções, como descritas aqui.

[00069] O armazenamento de dados 216 pode compreender um ou mais meios de armazenamento legíveis por computador, que podem ser lidos por pelo menos o processador 214. Os um ou mais meios de armazenamento legíveis por computador podem compreender componentes de armazenamento voláteis e/ou não voláteis, tais como memória óptica, magnética, orgânica ou outra, ou armazenamento em disco, que podem ser integrados no total ou em parte com o processador 214. Em algumas modalidades, o armazenamento de dados 216 é implementado usando um dispositivo físico (por exemplo, uma memória óptica, magnética, orgânica ou outra memória ou unidade de armazenamento em disco), enquanto que, em outras modalidades, o armazenamento de dados 216 é implementado usando dois ou mais dispositivo físicos.

[00070] O armazenamento de dados 216 pode incluir instruções de programa legíveis por computador 250 e possivelmente data. Instruções de programa legíveis por computador 250 podem incluir instruções executáveis por processador 214 e qualquer armazenamento requerido, respectivamente, para realizar pelo menos parte das técnicas aqui descritas e/ou pelo menos parte da funcionalidade dos dispositivos e redes aqui descritos.

[00071] A Figura 3 é um diagrama em blocos de um dispositivo de cliente de exemplo 104. O dispositivo de cliente 104 pode incluir interface de comunicações 310, interface de usuário 320, o coletor de feedback 330, o motor de regras 340, o coletor de dados 350, o analisador de texto 360, o analisador de dados 370, e interface de armazenamento de dados 380, todos conectados através da interconexão 390.

[00072] O arranjo de componentes do dispositivo de cliente 104, como mostrado na Figura 3 é um arranjo de exemplo. Em outras modalidades, o dispositivo de cliente 104 pode utilizar mais ou menos componentes do que mostrado na Figura 3 para realizar a funcionalidade aqui descrita do dispositivo de cliente 104.

[00073] A interface de comunicações 310 é configurada para permitir comunicações entre o dispositivo de cliente 104 e outros dispositivos, possivelmente incluindo permitir comunicações confiáveis, seguras e/ou autenticadas. Uma interface de comunicação de exemplo 310 é a interface de rede de comunicação 212, descrita acima no contexto da Figura 2. A interface de usuário 320 é configurada para permitir comunicações entre o dispositivo de cliente 104 e um usuário do dispositivo de cliente 104, incluindo, mas não limitada a, relatórios de comunicação (incluindo dados, análises, estratégias, e/ou sub-estratégias), pedidos, mensagens, feedback, relatório e/ou instruções, descritos aqui. Uma interface de usuário de exemplo 320 é a interface de usuário 210, descrita acima no contexto da Figura 2.

[00074] O coletor de feedback 330 é configurado para pedir, receber, armazenar, e/ou recuperar “feedback” ou entrada em relatórios, estratégias, e/ou sub-estratégias, como descritos aqui.

[00075] O motor de regras 340 é configurado para receber dados, analisar os dados recebidos, e gerar os relatórios correspondentes do DUS. O dado recebido pode incluir, mas não é limitado a, dado de reclamação, dado não processado relacionado ao teste, dado processado relacionado ao teste (por exemplo, uma análise estatística ou diferencial dos dados relacionados ao teste), os dados de referência, determinações de classificações/confiabilidade de dados recebidos, predeterminados valores de dado (por exemplo, “hard-coded data”), e/ou outros dados.

[00076] Os dados recebidos podem ser analisados por adaptação dos dados recebidos a uma ou mais regras e/ou uma população existente de dados. As uma ou mais regras podem ser armazenadas em regras de diagnóstico e base de dados de estratégia. Uma consulta à base de dados de regras e estratégia com respeito a dados recebidos (por exemplo, a reclamação) pode retornar uma ou mais regras e  possivelmente uma ou mais sub-estratégias se referem à reclamação.

[00077] Cada uma das uma ou mais regras relacionadas pode “disparar” (por exemplo, tornar-se aplicável) com base nos dados recebidos e/ou na população existente de dados. Por exemplo, uma consulta à base de dados de regras e estratégia pode incluir uma reclamação relacionada a “desempenho turbulento do motor”. As regras retornadas podem incluir uma primeira regra relacionada a fluxo de combustível que pode ser disparado com base nos dados de fluxo de combustível recebidos e/ou dados recebidos adicionais relacionados ao desempenho do DUS relacionado ao fluxo de combustível. Como outro exemplo, uma segunda regra relacionada a fluxo de combustível pode ser disparada na comparação de dados de fluxo de combustível recebidos com uma população “agregada” (por exemplo, previamente armazenada) de dados de fluxo de combustível. Muitas outras regras e/ou exemplos são também possíveis.

[00078] Com base nos dados recebidos, o motor de regras 340 pode determinar qual(is) regra(s) devem ser disparadas para determinar uma ou mais respostas associadas com as regras disparadas. Uma resposta possível inclui um conjunto de uma ou mais sub-estratégias para diagnóstico e/ou reparo do DUS 102. Sub-estratégias de exemplo incluem recomendações para “substituir o sensor de fluxo de combustível” ou “inspecionar o filtro de combustível”. Outras sub-estratégias de exemplo incluem pedido(s) para que um ou mais testes adicionais sejam realizados no DUS 102; por exemplo, “testar a voltagem da bateria” ou “operar o motor a 2500-3000 revoluções por minuto (RPMs)”. O(s) pedido(s) para teste(s) adicional(is) podem incluir instruções (isto é, instruções para um técnico, parâmetros de teste, e/ou instruções/comandos em linguagem de computador) para realizar o(s) teste(s) adicional(is) no DUS.

[00079] As uma ou mais respostas podem incluir dados de diagnóstico, tais como, mas não limitados a um ou mais valores de dados recebidos, os dados agregados, e/ou dados de linha de base, uma ou mais comparações entre dados recebidos, os dados agregados, e/ou dados de linha de base, e um ou mais valores e/ou comparações de valores de dados similares nos dados agregados, e/ou dados de linha de base, previamente recebidos. Outras respostas, sub-estratégias, os dados de diagnóstico, e/ou exemplos são também possíveis.

[00080] Uma sub-estratégia pode ser associada com uma estimativa de sucesso de sub-estratégia expressa como uma percentagem (por exemplo, “A recomendação 2 tem probabilidade de 28% que tenha sucesso”), como uma lista de ordem de sub-estratégias (por exemplo, uma sub-estratégia de ordem mais alta teria uma melhor estimativa de sucesso de sub-estratégia do que uma sub-estratégia de ordem mais baixa), como um valor numérico e/ou textual, (por exemplo, “A ação 1 tem um grau de 95, que é uma sub-estratégia ‘A’”), e/ou por algum outro tipo de expressão.

[00081] A estimativa de sucesso de sub-estratégia para uma certa sub- estratégia pode ser ajustada com base no feedback, tal como o feedback coletado pelo coletor de feedback 330, para uma determinada sub-estratégia. Como um exemplo: suponha que uma resposta incluiu três sub-estratégias: SS1, SS2 e SS3. Suponha ainda que o feedback foi recebida que SS1 não teve sucesso, SS2 teve sucesso, e SS3 não foi utilizada. Em resposta, a estimativa de sucesso de sub- estratégia para SS1 pode ser reduzida (isto é, tratada como sem sucesso), a estimativa de sucesso de sub-estratégia para SS2 pode ser aumentada (isto é, tratada como com sucesso), e a estimativa de sucesso de sub-estratégia para SS3 pode ser mantida. Outros ajustes baseados em feedback são também possíveis. Em algumas modalidades, estimativas de falha de sub-estratégia podem ser determinadas, armazenadas, e/ou ajustadas em lugar de (ou juntamente com) estimativas de sucesso de sub-estratégia; por exemplo, nessas modalidades, estimativas de falha de sub-estratégia podem ser ajustadas para baixo quando sub- estratégias correspondentes são com utilizadas com sucesso, e ajustadas para cima quando sub-estratégias correspondentes são utilizadas com sucesso.

[00082] Em ainda outras modalidades, uma ou mais determinada sub- estratégias no conjunto de uma ou mais sub-estratégias podem ser excluídas a partir de um relatório de DUS. Como um exemplo, um número máximo de sub-estratégias MaxSS pode ser fornecido, e sub-estratégias além do número máximo de sub- estratégias MaxSS poderiam ser excluídas. As sub-estratégias poderiam então ser selecionadas com base em vários critérios; por exemplo, a primeira (ou última) sub- estratégias MaxSS geradas pelo motor de regras 340, seleção aleatória de sub- estratégias MaxSS, com base em estimativas de sucesso de sub-estratégia, e/ou com base em estimativas de falha de sub-estratégia. Como outro exemplo, sub- estratégias cuja estimativa de sucesso de sub-estratégia não excedeu um valor de estimativa de sucesso limite (ou falhou em exceder um valor de estimativa de falha limite) pode ser excluído. Combinações desses critérios podem ser utilizadas; por exemplo, selecionar as primeiras sub-estratégias MaxSS que excederam o valor de estimativa de sucesso limite ou selecionar as sub-estratégias MaxSS que excederam o valor de estimativa de sucesso limite e têm as mais altas estimativas de sucesso de sub-estratégia dentre todas das sub-estratégias.

[00083] O relatório de DUS pode incluir parte ou toda da análise estatística, os dados de diagnóstico, e algumas ou todas das sub-estratégias de DUS 102. Outra informação, tal como relatório relacionado ao DUS 102 e/ou dados de reclamação podem ser fornecidos com o relatório de DUS.

[00084] Uma exposição de exemplo de um relatório de DUS é mostrada na tabela 1 abaixo:

TABELA 1

[00085] Embora este Relatório de DUS, de exemplo, seja mostrado com um relatório apenas em forma de texto, tipos adicionais de dados podem ser usados nos relatórios descritos aqui (incluindo, mas não limitados aos, relatórios de DUS) como tais, mas não limitados a dados visuais/gráficos/de imagem, os dados de vídeo, os dados de áudio, as ligações e/ou outros relatório de endereço (por exemplo, Localizadores Uniformes de Recursos (URLs), Indicadores Uniformes de Recursos (URIs), endereços de Protocolo de Internet (IP), endereços de Camada de Acesso ao Meio (MAC), e/ou outra informação de endereço), e/ou instruções de computador (por exemplo, Protocolo de Transferência de Protocolo de Transferência de Hipertexto (HTTP), eXtended Markup Language (XML), Flash ®, Java™ , JavaScript™ , e/ou outras instruções de linguagem de computador).

[00086] O coletor de dados 350 pode coordenar atividades de teste para um ou mais testes realizados durante uma “sessão de coleta de dados” do teste do DUS 102. Para executar um teste de uma sessão de coleta de dados, o coletor de dados 350 pode emitir “pedidos de teste do DUS” ou pedidos por dados relacionados ao DUS 102 e receber “dados relacionados ao teste do DUS” em resposta. Um pedido de teste de DUS pode ser relacionado a um ou mais “testes” para o DUS 102. Neste contexto, um teste do DUS 102 pode incluir realizar uma ou mais atividades (por exemplo, reparo, diagnósticos) no DUS 102, coletar dados a partir do DUS 102 (por exemplo, obter dados a partir de um ou mais sensores do DUS 102), e/ou receber dados relacionados ao dispositivo para o DUS 102 (isto é, receber dados relacionados ao dispositivo através de uma interface de usuário ou através de uma interface de rede de comunicação). Os dados relacionados ao teste do DUS para cada teste realizado durante a sessão de coleta de dados podem ser combinados em “Dados relacionados ao DUS” coletados durante a sessão inteira de coleta de dados. Os dados relacionados ao DUS podem incluir dados obtidos através de um registrador de dados operando para coletar dados durante a operação do DUS 102.

[00087] Alguns pedidos de teste do DUS podem ser feitos de acordo com um protocolo OBD-II, possivelmente através de comunicações usando um formato de mensagem OBD-II. Um formato de mensagem OBD-II pode incluir: dados de início de quadro e final de quadro, um identificador de mensagem, um identificador relacionado a mensagens remotas, um sinalizador de confirmação, os dados de verificação de redundância cíclica (CRC), e dados de carga paga de OBD-II. Os dados de carga paga de OBD-II podem incluir um campo de controle indicando um número de bytes em um campo de carga paga de OBD-II, e o campo de carga paga de OBD-II. O campo de carga paga de OBD-II pode especificar um modo de OBD-II, um parâmetro de OBD-II (PID), e dados de carga paga adicionais. Os modos de OBD-II, de exemplo, incluem, mas não são limitados a, modos para: mostrar dados atuais, mostrar dados de quadro congelado, mostrar um ou mais quadros de dados previamente gravados (por exemplo, “movies” de dados de OBD-II), mostrar Códigos de Problemas de Diagnóstico armazenados (DTCs), apagar DTCs e valores armazenados, resultados de teste para monitoração do sensor de oxigênio, resultados de teste para outros componentes, mostrar DTCs detectados durante o ciclo de condução atual ou o último ciclo de condução, controlar a operação do componente/sistema a bordo, pedir modo de informação do veículo, e um modo de DTC permanente/apagado. PIDs de OBD-II, de exemplo, incluem, mas não são limitados a, DTC congelado, estado do sistema de combustível, temperatura do agente de arrefecimento do motor, regulação fina do combustível, pressão do combustível, revoluções do motor/minuto (RPMs), velocidade do veículo, avanço de sincronização, e temperatura de ar de admissão. Muitos outros os modos de OBD-II e PIDs de OBD-II são também possíveis.

[00088] Quando dado relacionado aos pedidos de teste do DUS é coletado, o coletor de dados 350 pode atualizar uma exibição de coleta de dados para mostrar o progresso de coleta e teste dos dados. Uma exibição de coleta de dado de exemplo é descrita em mais detalhe com relação à Figura 5 abaixo. A conclusão da coleta de dados pode ser determinada por um motor de regras (por exemplo, o motor de  regras 340 e/ou o motor de regras 440).

[00089] O coletor de dados 350 pode receber e armazenar dado relacionado ao teste, possivelmente em um “perfil de DUS” associado com o DUS 102. O perfil de DUS pode ser criado, atualizado, e/ou deletado pelo coletor de dados 350.

[00090] Juntamente com os dados relacionados ao teste, o perfil de DUS pode ser configurado para os dados atualizados e/ou criados para armazenar dado relacionado a dispositivo, os dados de reclamação, relatórios de DUS, e/ou dados relacionados ao teste tomados em vários momentos durante a vida útil do DUS (por exemplo, dado de linha de base). Como tal, os dados armazenados no perfil de DUS podem ser um histórico de serviço de um DUS 102. Em algumas modalidades, o coletor de dados 350 pode gerar um relatório de perfil do DUS do histórico de serviço. Um relatório de perfil do DUS, de exemplo, é mostrado na tabela 2.

TABELA2

[00091] Como indicado acima, o relatório de perfil do DUS pode incluir uma referência aos dados relacionados ao teste, obtidos em vários momentos, relacionados ao DUS 102. Em outras modalidades, alguns ou todos dos dados obtidos relacionados ao teste podem ser incluídos diretamente no relatório de perfil do DUS. Em ainda outras modalidades, o relatório de perfil do DUS não inclui referências aos dados relacionados ao teste.

[00092] O analisador de texto 360 pode realizar uma “análise textual” dos dados de reclamação; isto é, o analisador de texto 360 pode analisar uma palavra, ou examinar de outra maneira, os dados de reclamação para encontrar palavras- chave e/ou frases relacionadas ao serviço (isto é, teste, diagnóstico e/ou reparo) do DUS 102. Por exemplo, suponha que os dados de reclamação incluídos em uma afirmação que “Meu carro está funcionado de forma turbulenta na marcha lenta, mas funciona suavemente na velocidade de cruzeiro”. Os dados de reclamação podem ser analisados por palavras-chave/frases, tais como “funcionando de forma turbulenta,” “marcha lenta”, “funciona suavemente” e “velocidade de cruzeiro” para pedir um ou mais testes do desempenho global do motor (por exemplo, com base nos termos “funcionando de forma turbulenta” e “funciona suavemente”) tanto em uma condição de “marcha lenta” condição quanto em uma condição de “velocidade de cruzeiro”. Muitos outros exemplos de palavras-chave/frases, os dados de reclamação, análise de palavras/exame dos dados de reclamação, e/ou pedidos de teste são também possíveis.

[00093] Em algumas modalidades, a reclamação pode ser especificada usando um “código de reclamação”. Por exemplo, uma reclamação que pode ser especificada como um código alfanumérico poderia ser usada; por exemplo, o Código E0001 representa uma falha geral do motor, o código E0002 representa um motor com marcha lenta turbulenta, etc. Nessas modalidades, os dados de reclamação podem incluir o código de reclamação. Em algumas das modalidades, o analisador de texto 360 pode gerar um ou mais códigos de reclamação como um resultado da análise textual da reclamação.

[00094] O analisador de dados 370 pode analisar dados relacionados ao DUS 102. Em particular, o analisador de dados pode gerar uma “análise estatística” comparando os dados recebidos relacionados ao DUS 102 e uma população existente de dados. A população existente de dados pode incluir, mas não é limitada a, os dados agregados, os dados de referência, e/ou dados armazenados relacionados ao DUS 102. Os dados de referência podem incluir dados provenientes do fabricante, fornecedor de componentes, e/ou outras fontes indicando os valores esperados para os dados para o DUS 102 quando DUS 102 está operando normalmente. Os dados armazenados relacionados ao DUS 102 podem incluir dados para o teste no dispositivo 102, capturados e armazenados em momento(s) antes da recepção dos dados recebidos. Estes dados armazenados podem incluir dados de linha de base para o DUS 102. Os dados de linha de base podem então ser armazenados, e possivelmente usados para comparações com os dados tomados durante a operação relacionada a uma reclamação (por exemplo, os dados relacionados ao teste acompanhados com os dados de reclamação). Em algumas modalidades, os dados agregados podem incluir alguns ou todos dos dados de referência e dados armazenados relacionados ao DUS 102. Como tal, os dados agregados podem ser tratados como a população existente de dados.

[00095] A análise estatística pode incluir a conjugação de dados recebidos com um subconjunto da população existente de dados, tal como por meio da conjugação de dados recebidos para um determinado DUS, com uma população existente de dados para o(s) dispositivo(s) que compartilham a mesma informação de dispositivo- núcleo (por exemplo, ano, modelo, marca, informação de ECU) com o dado DUS. Muitos outros tipos de conjugação de subconjunto da população existente de dados são também possíveis, tal como uso de outra informação diferente da informação de núcleo-dispositivo, estreitamento de um subconjunto de dados, e/ou expansão de um subconjunto de dados.

[00096] Um exemplo de estreitamento do subconjunto de dados inclui filtração do subconjunto de dados para uma emissão particular da ECU. Expansões de exemplo do subconjunto de dados incluem: adição de modelos similares de veículos compartilhando informação de núcleo-dispositivo, adição de dados de anos anteriores e/ou posteriores, e/ou adição de dados de diferentes marcas conhecidas que são fabricadas por um fabricante comum. Muitos outros exemplos de conjugação de subconjunto, estreitamento de subconjuntos de dados, e expansão de subconjuntos de dados são também possíveis.

[00097] A análise estatística pode incluir indicações da conjugação de valores entre os dados recebidos e a população existente de dados, faixa(s) de valores da população existente de dados e uma comparação de dados recebidos relativos à faixa (por exemplo, determinar se a temperatura do agente de arrefecimento para a população existente de dados está entre 68,3 e 79,4 °C (155 °F e 175 °F ) e a temperatura recebida do agente de arrefecimento de 71,1 °C (160 °F) está dentro desta faixa), e/ou determinar se estatísticas para os dados recebidos e/ou a população existente de dados (por exemplo, média, mediano, modo, variância, e/ou desvio padrão). A análise estatística pode incluir a análise de dados a partir de um ou mais sensores e/ou um ou mais tipos de dados (por exemplo, análise tanto dos dados de regulação fina do combustível quanto de pressão do combustível).

[00098] A análise estatística pode incluir comparações de dados recebidas a partir do DUS 102 ao longo do tempo. Por exemplo, os dados recebidos podem ser comparados com os dados de linha de base para o DUS 102 para gerar a análise estatística e/ou uma análise diferencial entre os dados de linha de base dos dados recebidos. Na geração da análise estatística e/ou análise diferencial, o analisador de dados 370 pode usar uma ou mais das técnicas para a classificação dos dados relacionados ao teste, como discutido abaixo no contexto da Figura 4. Por exemplo, o analisador de dados 370 pode classificar um ou mais valores de dado como dados de linha de base.

[00099] Adicionalmente ou ao invés de os dados recebidos gerados dentro de um intervalo de tempo de teste (por exemplo, o dado recebido inclui um número de amostras de dado que são coletadas em vários momentos durante o intervalo de tempo de teste) podem ser estatisticamente analisados; por exemplo, para determinar estatísticas dentro do intervalo de teste, para remover ou determinar pontos de dado que se situam fora, e/ou para outros tipos de análise estatística. Em algumas modalidades, os dados de referência e/ou dados agregados podem ser usados como dados de linha de base. Em ainda outras modalidades, os dados na população existente de dados podem ser estatisticamente analisados dentro dos intervalos de tempo de teste.

[000100] A interface de armazenamento de dados 380 é configurada para armazenar e/ou recuperar dados e/ou instruções utilizados pelo dispositivo de cliente 104. Uma interface de armazenamento de dados 380, de exemplo, é o armazenamento de dados 216, descrito acima no contexto da Figura 2.

[000101] A Figura 4 é um diagrama em blocos de um dispositivo de servidor de exemplo 106. O dispositivo de servidor 106 pode incluir interface de comunicações 410, o agregador de dados 420, o analisador de dados 430, o motor de regras 440, o analisador de texto 450, o coletor de dados 460, o coletor de feedback 470, e interface de armazenamento de dados 480, todos conectados através da interconexão 490.

[000102] O arranjo de componentes do dispositivo de servidor 106, como mostrado na Figura 4, é um arranjo de exemplo. Em outras modalidades, o dispositivo de servidor 106 pode utilizar mais ou menos componentes do que os mostrados na Figura 4 para realizar a funcionalidade aqui descrita do dispositivo de servidor 106.

[000103] A interface de comunicações 410 é configurada para permitir comunicações entre dispositivo de servidor 106 e outros dispositivos. Uma interface de comunicação 410, de exemplo, é a interface de rede de comunicação 212, descrita acima no contexto da Figura 2.

[000104] O agregador de dados 420 pode criar, atualizar, e/ou deletar um perfil de DUS associado com o DUS 102 e possivelmente gerar um relatório de perfil relacionado do DUS usando as técnicas descritas acima com relação à Figura 3. Assim, o dispositivo de cliente 104 e/ou dispositivo de servidor 106 pode manter perfil de DUS(s) e gerar o relatório de perfil do DUS(s).

[000105] O agregador de dados 420 pode classificar dados com base em uma reclamação. Por exemplo, todos os dados relacionados a teste, que se relacionam com reclamações acerca dos DUSs que falham em iniciar podem ser classificados como dados relacionados a reclamações “falhando em iniciar”. Na agregação em um conjunto de dados compartilhando uma classificação em comum, uma porção dos dados pode ser retida como dados agregados. Por exemplo, os dados na classificação “falhando em iniciar” relacionados a arranques, baterias, e sistemas elétricos poderiam ser agregados. Outros dados podem ser também agregados, ou agregados em outra classificação, e/ou descartados. Por exemplo, os dados que provavelmente não são correlacionados com uma reclamação podem ser reclassificados e agregados com base na reclassificação. Neste contexto, os dados relacionados a pressões dos pneus, transportados como parte de dados relacionados ao teste “falhando em iniciar”, poderia ser reclassificados como “dados de pressão de pneu” e então agregados. Muitos outros tipos de agregação com base em classificações orientadas por reclamação são também possíveis.

[000106] O agregador de dados 420 pode classificar dado relacionado ao teste com base em confiabilidade. A classificação de dados relacionado ao teste quanto à confiabilidade pode incluir a comparação de valores de dado dos dados relacionados ao teste com os dados de valores de referência e/ou de linha de base. Algumas técnicas de exemplo para comparar valores de dado com os dados de valores de referência/de linha de base são para determinar que: - um valor de dado é o mesmo que um ou mais valores de referência/linha de base (por exemplo, uma leitura de pressão de pneu TPR é 32 libras por polegada quadrada (PSI); um nome do fabricante é “Tuftrux”), - o valor de dado está dentro de uma faixa de valores de dados (por exemplo, TPR é entre 28 e 34 PSI), - o valor de dado está acima e/ou abaixo de um valor limite de um valor de referência/linha de base (por exemplo, TPR está na faixa de 31 ± t PSI, onde t = o valor de limite/linha de base), - o valor de dado começa com, termina com, ou contém o valor de referência/linha de base (por exemplo, um número de identificação de veículo (VIN) começa com um “1” ou contém a sequência de caracteres “1GT”), - cada um de um número de valores de dado é o mesmo, dentro de uma faixa, e/ou dentro de um limite de um valor de referência/linha de base (por exemplo, leituras de pressão de pneu para os quatro pneus estão todas dentro de 28-34 PSI), - computação(ões) no(s) valor(es) de dado, possivelmente incluindo valores de referência e/ou de linha de base, são calculadas e possivelmente comparadas com os valores de referência e/ou de linha de base (por exemplo, fazer um valor médio de um número de valores de dado, converter Valores de dado de medida do sistema Inglês para os equivalentes em unidade do sistema métrico e comparar os valores convertidos para valores de referência de unidade métrica, usar valores de dado em uma fórmula e comparar o resultado da fórmula com valores de referência), e/ou - negações dessas condições (por exemplo, uma temperatura não está dentro da faixa de 43,3 a 54,4 °C (110-130 °F)).

[000107] Muitas outras técnicas para determinar valores de dado são confiáveis com base em dados de referência e/ou de linha de base são também possíveis.

[000108] Dados de referência e/ou de linha de base podem incluir predeterminados valores (por exemplo, 28 PSI), faixas (por exemplo, 28-34 PSI), limites (por exemplo, um limite de 3 PSI), fórmulas (por exemplo, C = 1,8 * F), e/ou padrões de conjugação (por exemplo, “1*2” como um padrão que se conjuga a uma de uma sequência que começa com um “1” e termina com um “2”).

[000109] Dados de referência e/ou de linha de base podem também ser baseados em valores de dado previamente classificados como confiáveis. Por exemplo, suponha que três dos dispositivos tinham respectivas leituras de temperatura de 98, 99, e 103 graus, e que todas as três leituras de temperatura eram confiáveis. Então, a média A desses três valores (100 graus) e/ou faixa R desses três valores (5 graus) pode ser usada como valores de referência: por exemplo, um valor de dado de temperatura pode ser comparado com A, A + R, A - R, A ± R, A ± cR, para um valor constante c, c1A ± c2R para valores constantes c1, c2). Muitas outras bases para uso de valores de dado confiáveis como dados de referência e/ou de linha de base são também possíveis.

[000110] Dados de referência e/ou de linha de base podem ser baseados em uma seleção estatística de data. A seleção estatística pode envolver a geração de uma ou mais estatísticas para dados a serem agregados nos dados de referência e/ou de linha de base e então agregar os dados com base nas estatísticas geradas.

[000111] Por exemplo, suponha que dado relacionado ao teste incluiu um valor de medição de Meas1 obtido usando um sensor Sens1. Suponha ainda que dados agregados relacionados ao valor de medição a partir do sensor Sens1 indicaram um valor de medição médio de MeanMeas1 com um desvio padrão de SDMeas1. Então, um número de desvios padrão NSD a partir da média MeanMeas1 para Meas1 poderia ser determinado, possivelmente usando a fórmula

[000112] Então, o valor de medição Meas1 poderia ser agregado ao dado agregado relacionado ao sensor Sens1 quando número de desvios padrão NSD é inferior a, ou igual a um número limite de desvios padrão NSD_Limite. Por exemplo, se NSD_Limite = 2, então Meas1 seria agregado aos dados agregados se Meas1 estivesse dentro de 2 desvios padrão da média MeanMeas1.

[000113] Em algumas modalidades, a seleção estatística para um conjunto de valores de dado pode ser realizada somente se um número predeterminado de valores de dado N foi agregado ao conjunto de valores de dado. Nessas modalidades, se o número de valores agregados de dados é inferior a N, então valores de dado podem ser agregados sem seleção estatística até pelo menos N valores de dado terem sido agregados. Em algumas modalidades, N pode ser suficientemente grande para agrupar dados sem a seleção por um considerável período de tempo (por exemplo, um ou mais meses). Então, depois da considerável quantia de tempo, a seleção pode ser realizada, permitindo assim a coleta de dados durante a considerável quantia de tempo sem focar sobre valores bons ou que falharam. Muitos outros tipos de seleção estatística são também possíveis.

[000114] O agregador de dados 420 pode classificar dado relacionado ao teste em conexão com motor de regras 440. Em algumas modalidades, o motor de regras 440 pode instruir o agregador de dados 420 para usar uma ou mais técnicas para a classificação de um ou mais valores de dado nos dados relacionados ao teste. Em outras modalidades, o agregador de dados 420 pode comunicar alguns ou todos dos dados relacionados ao teste e/ou alguns ou todos dos valores de linha de base para o motor de regras 440, o motor de regras 440 pode classificar do dado relacionado ao teste e subsequentemente comunicar uma classificação do dado relacionado ao teste para o agregador de dados 420. Em algumas dessas outras modalidades, o agregador de dados 420 pode realizar uma classificação preliminar para dado relacionado ao teste; e em uma classificação preliminar que o dado relacionado ao teste é confiável, comunicar alguns ou todos dos dados relacionados ao teste e/ou alguns ou todos dos valores de linha de base para o motor de regras 440 para uma determinação final de confiabilidade. Dados de confiabilidade determinados finalmente podem então ser adicionados ao dado de linha de base, como descrito acima. Em ainda outras modalidades, o agregador de dados 420 pode determinar se o dado relacionado ao teste é confiável sem se comunicar com motor de regras 440.

[000115] Tais dados de valores de dado e/ou de referência classificados podem ser combinados ou agregados nos dados agregados pelo agregador de dados 420. O dado agregado pode ser atualizado ao longo do tempo; por exemplo, valores de dado classificados podem ser adicionados ou combinados de outra maneira com o dado agregado com base em uma classificação dos valores de dado. Em algumas modalidades, os dados agregados podem incluir valores de dado que não foram classificados; por exemplo, populações total de dados, ou todos os dados para um DUS específico. O dado agregado pode ser armazenado, possivelmente em uma base de dados, e posteriormente recuperado e usado para classificações e/ou para  outras finalidades.

[000116] O analisador de dados 430 pode analisar dados relacionados ao DUS 102, tal como descrito acima para o analisador de dados 370 no contexto da Figura 3.

[000117] O motor de regras 440 pode receber dados, possivelmente incluindo dados de reclamação, analisar os dados recebidos, e gerar correspondentes relatórios de DUS, tal como descrito acima para o motor de regras 340 no contexto da Figura 3.

[000118] O analisador de texto 450 pode analisar uma palavra, ou examinar de outra maneira, os dados de reclamação para encontrar palavras-chave e/ou frases relacionadas ao serviço do DUS 102, tal como descrito acima para o analisador de texto 360 no contexto da Figura 3.

[000119] O coletor de dados 460 pode coordenar atividades de teste para um ou mais testes realizados durante a sessão de coleta de dados do teste do DUS 102, tal como descrito acima para o coletor de dados 450 no contexto da Figura 3.

[000120] O coletor de feedback 470 é configurado para pedir, receber, armazenar, e/ou recuperar “feedback” ou entrada em relatórios e/ou sub-estratégias, tal como descrito acima para o coletor de feedback 330 no contexto da Figura 3.

[000121] A interface de armazenamento de dados 480 é configurada para armazenar e/ou recuperar dados e/ou instruções utilizados pelo dispositivo de servidor 106. Um exemplo de interface de armazenamento de dados 460 é o armazenamento de dados 216, descrito acima no contexto da Figura 2.

[000122] A Figura 5 representa uma exibição de coleta de dado de exemplo 500, incluindo identificação de DUS 510, a barra do estado global 520, estado de diagnóstico detalhado 530, e barras de estado do teste 540, 542, 544, e 546.

[000123] A identificação de DUS 510 pode incluir dado relacionado a dispositivo que especifica um DUS. A barra de estado global 520 pode mostrar visualmente, numericamente, e/ou textualmente o estado de uma sessão de coleta de dados. Como mostrado na Figura 5, a barra do estado global 520 mostra graficamente, textualmente e numericamente a conclusão em percentagem da sessão de coleta de  dados; neste exemplo, a sessão de coleta de dados está 63% completa.

[000124] O estado de diagnóstico detalhado 530 pode fornecer relatório de progresso adicional acerca da sessão de coleta de dados, tal como, mas não limitada ao, estado de comunicação (por exemplo, a “Comunicação Estabelecida” e indicadores de “Comunicação” mostrados na Figura 5), estado de entrada de dados (por exemplo, o indicador de “Reclamação Capturada” mostrado na Figura 5), estado de captura de dados relacionados ao teste (por exemplo, os indicadores de “Verificação de Códigos”, ”Monitores”, e “Coletar Dados”, mostrados na Figura 5), e estado de análise (por exemplo, o indicador de “Análise de Dados” mostrado na Figura 5).

[000125] As barras de estado de teste 540, 542, 544, e 546 podem fornecer o estado de um ou mais testes conduzidos durante a sessão de coleta de dados. Como mostrado na Figura 5, as barras de estado do teste 540, 542, 544, e 546 graficamente, mostram textualmente e numericamente, cada, respectivamente, a conclusão em percentagem de um teste; por exemplo, a barra de estado de teste 540 da Figura 5 mostra que o “Teste de Arranque” está 80% completo.

[000126] Em algumas modalidades, a exibição de coleta de dados 500 pode ser melhorada com o uso de instruções e/ou tons audíveis. Por exemplo, uma instrução de mensagem sonora e/ou audível pode ser usada para informar um técnico de veículo para mudar o estado de operação e/ou realizar outro teste de um dispositivo em serviço; por exemplo, uma mensagem sonora ou instrução para: “Por favor, aumente agora a aceleração para operar o veículo a 2500 RPM”. Como outro exemplo, uma instrução de mensagem sonora e/ou audível pode ser usada para informar que a operação está fora das faixas esperadas; por exemplo, para um teste a 2500 RPM, uma instrução de mensagem sonora e/ou audível pode instruir o técnico para aumentar a aceleração quando a taxa de RPMs está abaixo da desejada taxa de 2500 RPM. Adicionalmente, texto que corresponde a tais instruções audíveis pode ser exibido na exibição de coleta de dados 500.

III. COMUNICAÇÕES DE EXEMPLO

[000127] Uma variedade de comunicações pode ser executada via a rede 110.  Exemplos daquelas comunicações são ilustradas nas Figuras 6A, 6B, 6C, 6D, 7A, 7B e 7C. As comunicações mostradas nas Figuras 6A, 6B, 6C, 6D, 7A, 7B, e 7C podem ser na forma de mensagens, sinais, pacotes, unidades de dado de protocolo (PDUs), quadros, fragmentos e/ou qualquer outro tipo apropriado de comunicação configurada para ser comunicada entre os dispositivos.

[000128] A Figura 6A mostra um cenário de exemplo 600 para processar pedido de diagnóstico 610, gerando responsivamente a exibição do relatório de DUS 632, e recebendo dado relacionado ao sucesso 640. O cenário 600 começa com o pedido de diagnóstico 610 sendo recebido no dispositivo de cliente 104. O dispositivo de cliente 104 inspeciona o pedido de diagnóstico 610 para determinar um ou mais testes relacionados ao DUS 102 e gerar responsivamente o pedido de teste de DUS 612 para realizar os um ou mais testes, e comunica o pedido de teste de DUS 612 para o DSU 102. Em algumas modalidades, o coletor de dados 350 do dispositivo de cliente 104 gera o pedido de teste de DUS 612. Em algumas modalidades, o pedido de teste de DUS 612 é formatado de acordo com um protocolo OBD-II.

[000129] O dispositivo de cliente 104 também inspeciona o pedido de diagnóstico 610 quanto a uma reclamação (mostrada na Figura 6A como “C1” com o pedido de diagnóstico 610). Em algumas modalidades, a reclamação C1 não é ainda inspecionada no dispositivo de cliente 104; enquanto que, em outras modalidades, o analisador de texto 360 pode realizar uma análise textual da reclamação C1. A reclamação C1 pode ser fornecida por um usuário como texto e/ou como um código de reclamação, como mencionado acima.

[000130] Na recepção do pedido de teste de DUS 612 no DUS 102, os um ou mais testes são realizados. O dado resultante dos um ou mais testes é coletado e comunicado a partir do DUS 102 para o dispositivo de cliente 104 como dado relacionado ao DUS 614. O dispositivo de cliente 104 então comunica dado relacionado ao DUS e reclamação C1 para o dispositivo de servidor 106 usando dado relacionado ao DUS 616.

[000131] A Figura 6A mostra que, em resposta a dado relacionado ao DUS 616, o dispositivo de servidor gera o pedido de diagnóstico 620 com um pedido para um ou mais testes adicionais (representados como T1). Detalhes da geração do pedido de diagnóstico 620 são descritos abaixo com relação à Figura 6B.

[000132] Na recepção do pedido de diagnóstico 620, o dispositivo de cliente 104 comunica o pedido de teste de DUS 622 para executar os testes adicionais T1. Na recepção do pedido de teste de DUS 622 no DUS 102, os um ou mais testes adicionais T1 são realizados. Dado a partir dos um ou mais testes adicionais é coletado e comunicado a partir do DUS 102 para o dispositivo de cliente 104 como dado relacionado ao DUS 624. O dispositivo de cliente 104 então comunica dado relacionado ao DUS e reclamação C1 para o dispositivo de servidor 106 usando dado relacionado ao DUS 626. Em alguns cenários não mostrados na Figura 6A, dado relacionado ao DUS 626 não inclui a reclamação C1 quando C1 já foi comunicada ao dispositivo de servidor 106 (via dado relacionado ao DUS 616) e assim C1 poderia ser armazenada pelo dispositivo de servidor 106.

[000133] A Figura 6A mostra que, em resposta a dado relacionado ao DUS 626, o dispositivo de servidor 106 gera o relatório de DUS 630 com a estratégia S1 e comunica o relatório de DUS 630 para o dispositivo de cliente 630. Em algumas modalidades, estratégia S1 inclui uma ou mais sub-estratégias SS1, SS2, etc. para endereçar reclamação C1. Sub-estratégias para endereçar reclamações são discutidas acima em mais detalhe com relação à Figura 3 Detalhes da geração de Relatório de DUS 630 são descritos abaixo com relação à Figura 6C.

[000134] Em resposta à recepção do relatório de DUS 630, o dispositivo de cliente 104 gera e comunica a exibição do relatório de DUS 632. Uma exibição do relatório de DUS, de exemplo, é mostrada na tabela 1 acima. Depois da comunicação da exibição do relatório de DUS 632, o cenário 600 continua com o dispositivo de cliente 104 recebendo dado relacionado ao sucesso 640. A Figura 6A mostra dado relacionado ao sucesso 640 com F(SS1), que é feedback F para a sub- estratégia SS1 da estratégia S1. O feedback nas sub-estratégias é discutido acima em mais detalhe com relação à Figura 3. Em resposta a dado relacionado ao sucesso 640, o dispositivo de cliente 104 comunica correspondentes dados relacionados ao sucesso 642 com F(SS1) para o dispositivo de servidor 106.

[000135] Em alguns cenários não mostrados na Figura 6A, o dispositivo de servidor 106 pode enviar um relatório de DUS em resposta a dado relacionado ao DUS 616 (isto é, o dispositivo de servidor 106 não pede testes/dados adicionais). Em outros cenários não mostrados na Figura 6A, o dispositivo de servidor 106 pode enviar dois ou mais pedidos de diagnóstico para pedir mais teste(s) adicional(is). Em outros cenários não mostrados na Figura 6A, o dispositivo de cliente 104 pode receber e analisar dado relacionado ao DUS 616 e 626 para gerar o relatório de DUS 630, tal como descrito abaixo em mais detalhe com relação às Figuras 7A, 7B, e 7C. Isto é, o dispositivo de cliente 104 pode realizar algumas ou todas das funcionalidades descritas aqui com relação um dispositivo de servidor 106 nos cenários 600, 650, e/ou 680. Em ainda outros cenários não mostrados na Figura 6A, nenhum dado relacionado ao sucesso é recebido em resposta à exibição do relatório de DUS 632 (isto é, nenhum feedback sobre a estratégia S1 é fornecido para o dispositivo de cliente 104 e/ou o dispositivo de servidor 106).

[000136] A Figura 6B mostra um cenário de exemplo 650 para processar dado relacionado ao DUS 616 e gerar responsivamente o pedido de diagnóstico 620. Dado relacionado ao DUS com reclamação C1 616 é recebido na interface de comunicações 410 do dispositivo de servidor 106. A Figura 6B mostra que a consulta de reclamação 662 é gerada pelo analisador de texto 450 em resposta à reclamação C1 660. A consulta de reclamação 662 pode incluir palavras-chave/frases, como determinadas com base na análise textual da reclamação C1, tal como descrito acima com relação à Figura 3.

[000137] Dado relacionado ao DUS 670 é comunicado da interface de comunicações 410 para tanto agregador de dados 420 quanto analisador de dados 430. A Figura 6B mostra que a reclamação C1 não é incluída com dado relacionado ao DUS 670; mas, em algumas modalidades não mostradas na Figura 6B, dado relacionado ao DUS 670 inclui C1 (isto é, é uma cópia de como dado relacionado ao DUS 616).

[000138] Na recepção de dado relacionado ao DUS 670, o agregador de dados 420 e/ou o motor de regras 440 pode classificar dado relacionado ao DUS usando as técnicas descritas acima no contexto da Figura 4. Como parte da classificação, o agregador de dados 420 pode consultar ou acessar de outra maneira os dados agregados 672 para determinar o dado de linha de base 674 (mostrado na Figura 6B como a “Base dados 674”) para dado relacionado ao DUS 670. Na classificação de dado relacionado ao DUS 670, a classificação 676 (mostrada na Figura 6B como a “Classe 676”) pode ser gerada pelo agregador de dados 420 e/ou o motor de regras 440. Uma vez quando gerada, a classificação 676 pode ser comunicada para o motor de regras 440. Adicionalmente, dado relacionado ao DUS 670 pode ser armazenado, possivelmente de acordo com e/ou juntamente com a classificação 670, pelo agregador de dados 420 nos dados agregados 672.

[000139] Na recepção de dado relacionado ao DUS 670, o analisador de dados 430 pode gerar a análise estatística (SA) 678 de dado relacionado ao DUS 670, possivelmente com base em dado de linha de base 674, usando as técnicas descritas acima no contexto das Figuras 3 e 4. O analisador de dados 430 pode comunicar análise estatística 678 para o motor de regras 440.

[000140] Na recepção da consulta de reclamação 662, a classificação 676, e análise estatística 672, o motor de regras 440 pode comunicar a consulta 666 com os dados de reclamação (mostrados na Figura 6B como “Comp”) e análise estatística SA para a regras de diagnóstico e base de dados de estratégia 664 (mostrada na Figura 6B como “Diag Regras/Strat 664”) usando as técnicas descritas acima no contexto das Figuras 3 e 4. Em resposta, regras de diagnóstico e base de dados de estratégia 664 pode comunicar estratégia 668 (mostrada na Figura 6B como “S0”) incluindo uma ou mais regras e sub-estratégias associadas para o motor de regras 440. Usando as técnicas descritas acima no contexto das Figuras 3 e 4, o motor de regras 440 pode determinar quais regras(s) da estratégia 668 disparar, e assim determinar as sub-estratégia/sub-estratégias associadas à(s) regra(s) disparada(s). No cenário 650, o motor de regras 640 determina qual dado adicional é requerido, com base nas regra(s) disparado e sub-estratégia/sub-estratégias associadas. O motor de regras 640 pode gerar pedido de diagnóstico 620 para executar teste(s) T1 para obter o dado adicional e comunicar o pedido de diagnóstico 620 para a interface de comunicações 410. A interface de comunicações 410 pode então enviar o pedido de diagnóstico 620.

[000141] A Figura 6C mostra um cenário de exemplo 680 para processar dado relacionado ao DUS 626 e gerar responsivamente o relatório de DUS 630. Dado relacionado ao DUS com reclamação C1 626 é recebido na interface de comunicações 410 do dispositivo de servidor 106. Nos cenários não mostrados na Figura 6C, a reclamação C1 pode ser analisada por um analisador de texto para determinar uma consulta de reclamação. Entretanto, o cenário 680 assume que C1 já foi analisado por um analisador de texto, tal como descrito acima com relação às Figuras 3 e 6B.

[000142] Dado relacionado ao DUS 682 é comunicado a partir da interface de comunicações 410 para o analisador de dados 430. Nos cenários não mostrados na Figura 6C, dado relacionado ao DUS 626 é fornecido para um agregador de dados para possivelmente ser combinado com dado agregado, tal como descrito acima nas Figuras 4 e 6B. A Figura 6C mostra que a reclamação C1 não é incluída com dado relacionado ao DUS 682; mas, em algumas modalidades não mostradas na Figura 6C, dado relacionado ao DUS 682 inclui C1 (isto é, é uma cópia de dado relacionado ao DUS 626).

[000143] Na recepção de dado relacionado ao DUS 682, o analisador de dados 430 pode gerar a análise estatística 686 (mostrada na Figura 6C como “SA2”) de dado relacionado ao DUS 682, usando as técnicas descritas acima no contexto das Figuras 3, 4, e 6B. O analisador de dados 430 pode comunicar análise estatística 2 686 para o motor de regras 440.

[000144] Na recepção da análise estatística 686, o motor de regras 440 pode comunicar consulta 688 com os dados de reclamação previamente determinado (mostrados na Figura 6C como “Comp”) e análise estatística 686 para a regras de diagnóstico e base de dados de estratégia 664 (mostrada na Figura 6C como “Diag Rules/Strat 664”) usando as técnicas descritas acima no contexto das Figuras 3 e 4. Em resposta, regras de diagnóstico e base de dados de estratégia 664 pode comunicar estratégia 690 (mostrada na Figura 6B como “S1+”) incluindo uma ou mais regras e sub-estratégia/sub-estratégias associadas para o motor de regras 440. Usando as técnicas descritas acima no contexto das Figuras 3 e 4, o motor de regras 440 pode determinar quais regra(s) devem ser disparadas e suas sub- estratégia/sub-estratégias associadas. No cenário 680, o motor de regras 640 gera o relatório de DUS 630 que pode incluir alguma ou toda da análise estatística 686 e/ou alguma ou todas das sub-estratégias da estratégia 690 (coletivamente mostrada na Figura 6C como “S1”) e comunica o relatório de DUS 630 para a interface de comunicação 410. A interface de comunicações 410 pode então enviar o relatório de DUS 630.

[000145] A Figura 6D mostra outro cenário de exemplo 600a para processar pedido de diagnóstico 610, gerando responsivamente a exibição do relatório de DUS 632, e recebendo dado relacionado ao sucesso 640. O cenário 600a é uma alternativa para o cenário 600 onde o dispositivo de servidor 106 direciona o teste do DUS 102, em lugar do dispositivo de cliente 104.

[000146] O cenário 600a começa com o pedido de diagnóstico 610 sendo recebido no dispositivo de cliente 104. O dispositivo de cliente 104 transmite o pedido de diagnóstico 610 como pedido de diagnóstico 610a para o dispositivo de servidor 106. O dispositivo de servidor 106 pode examinar o pedido de diagnóstico 610a para determinar um ou mais testes relacionados ao DUS 102 e gerar responsivamente o pedido de teste de DUS 612 para realizar os um ou mais testes e comunica o pedido de teste de DUS 612 para o DSU 102.

[000147] O dispositivo de servidor 106 pode inspecionar o pedido de diagnóstico 610 para a reclamação (mostrada na Figura 6C como “C1” com o pedido de diagnóstico 610a). Em algumas modalidades, a reclamação C1 não é ainda inspecionada no dispositivo de servidor 106; enquanto que, em outras modalidades, o analisador de texto 450 pode realizar uma análise textual da reclamação C1. A reclamação C1 pode ser fornecida por um usuário como texto e/ou como um código de reclamação, como mencionado acima.

[000148] Na recepção do pedido de teste de DUS 612a no DUS 102, os um ou mais testes são realizados. Dado resultantes a partir dos um ou mais testes é coletado e comunicado a partir do DUS 102 para o dispositivo de servidor 106 como dado relacionado ao DUS 614a.

[000149] A Figura 6D mostra que, em resposta a dado relacionado ao DUS 614a, o dispositivo de servidor 106 gera o pedido de teste de DUS 622a para executar um ou mais testes adicionais (representados como T1). O dispositivo de servidor 106 gera o pedido de teste de DUS 622a usando técnicas similares às técnicas descritas na Figura 6B para geração do pedido de diagnóstico 620.

[000150] Na recepção do pedido de teste de DUS 622a no DUS 102, os um ou mais testes adicionais T1 são realizados. Dado a partir dos um ou mais testes adicionais é coletado e comunicado a partir do DUS 102 para o dispositivo de servidor 106 como dado relacionado ao DUS 624a.

[000151] A Figura 6D mostra que, em resposta a dado relacionado ao DUS 624a, o dispositivo de servidor 106 gera o relatório de DUS 630 com a estratégia S1 e comunica o relatório de DUS 630 para o dispositivo de cliente 630. Detalhes da geração do Relatório de DUS 630 são descritos acima com relação à Figura 6C.

[000152] O restante do cenário 600a com relação à exibição do relatório de DUS 632, dado relacionado ao sucesso 640, e dado relacionado ao sucesso 642 com F(SS1), é o mesmo que como discutido acima para o cenário 600 no contexto da Figura 6A.

[000153] Em alguns cenários não mostrados na Figura 6D, o dispositivo de servidor 106 pode enviar um relatório de DUS em resposta a dado relacionado ao DUS 614a (isto é, o dispositivo de servidor 106 não pede testes/dados adicionais). Em outros cenários não mostrados na Figura 6D, o dispositivo de servidor 106 pode enviar dois ou mais pedidos de teste de DUS para pedido(s) de teste adicional(is). Em ainda outros cenários não mostrados na Figura 6D, nenhum dado relacionado ao sucesso é recebido em resposta à exibição do relatório de DUS 632 (isto é, nenhum feedback sobre a estratégia S1 é fornecido para o dispositivo de cliente 104 e/ou dispositivo de servidor 106).

[000154] a Figura 7A mostra um cenário de exemplo 700 para processar pedido de diagnóstico 710, gerando responsivamente a exibição do relatório de DUS 730, e recebendo dado relacionado ao sucesso para a exibição do relatório de DUS 732 no dispositivo de cliente 104. Em algumas modalidades não mostradas na Figura 7A, algumas ou todas das técnicas e comunicações que envolvem o dispositivo de cliente 104 podem ser realizadas pelo dispositivo de servidor 106.

[000155] O dispositivo de cliente 104 pode determinar um ou mais testes relacionados ao DUS 102 com base no pedido de diagnóstico recebido 710 e gerar responsivamente o pedido de teste de DUS 720 para o DSU 102 para realizar os um ou mais testes. Em algumas modalidades, o coletor de dados 350 gera o pedido de teste de DUS 720. Em algumas modalidades, o pedido de teste de DUS 720 é formatado de acordo com um protocolo OBD-II.

[000156] O(s) teste(s) no pedido de teste de DUS 720 se refere(m) a um primeiro estado de operação (mostrado como “Estado1” na Figura 7A) do DUS 102. Estados de operação de exemplo do DUS 102 incluem um estado de operação sem carga/ligeiramente carregado (por exemplo, um estado de operação “de marcha lenta”), vários estados de operação sob cargas normais (por exemplo, um estado de operação de “cruzeiro”, um estado de operação de “arranque”), e estados de operação na, ou perto da, carga máxima (por exemplo, um estado de operação de “alta velocidade”). Outros estados de operação são também possíveis.

[000157] O dispositivo de cliente 104 pode inspecionar o pedido de diagnóstico 710 para a reclamação (mostrada na Figura 7A como “C2” com o pedido de diagnóstico 710). Reclamação C2 pode ser fornecida por um usuário como texto e/ou como um código de reclamação, como mencionado acima. No cenário 700, o dispositivo de cliente 104 (por exemplo, o analisador de texto 360) pode realizar uma análise textual da reclamação C2.

[000158] Na recepção do pedido de teste de DUS 720 no DUS 102, os um ou mais testes associados com o primeiro estado de operação Estado1 são realizados. Dados a partir dos um ou mais testes são coletados e comunicados ao dispositivo de cliente 104 como dado relacionado ao DUS 722.

[000159] Nos cenários não mostrados na Figura 7A, uma ou mais sequências adicionais de pedidos de teste do DUS e dado relacionado ao DUS podem ser  comunicados entre o dispositivo de cliente 104 e o DUS 102; por exemplo, para comunicar dados adicionais requeridos enquanto o DUS 102 está operando ou no primeiro estado de operação Estado1 ou para comunicar dados enquanto o DUS 102 está operando em outro(s) estado(s) de operação diferente do primeiro estado de operação Estado1.

[000160] a Figura 7A mostra que, em resposta à recepção de dado relacionado ao DUS 722, o dispositivo de cliente 104 gera e comunica a exibição do relatório de DUS 730 relacionado à estratégia S2. Uma exibição do relatório de DUS, de exemplo, é mostrada acima na tabela 1. Depois da comunicação da exibição do relatório de DUS 730, o cenário 700 continua com o dispositivo de cliente 104 recebendo dado relacionado ao sucesso 732. A Figura 6A mostra dado relacionado ao sucesso 730 com F(SS3, SS4), que é feedback F para as sub-estratégias SS3 e SS4 da estratégia S2. O feedback em sub-estratégias é discutido acima em mais detalhe com relação à Figura 3 e a Figura 6A. Em outros cenários não mostrados na Figura 7A, nenhum dado relacionado ao sucesso é recebido em resposta à exibição do relatório de DUS 730 (isto é, nenhum feedback sobre a estratégia S2 é fornecido para o dispositivo de cliente 104).

[000161] A Figura 7B mostra um cenário de exemplo 750 para processar pedido de diagnóstico 710 e gerando responsivamente o pedido de teste de DUS 720. O pedido de diagnóstico com reclamação C2 710 é recebido na interface de comunicações 310 do dispositivo de cliente 104. A Figura 7B mostra que, a consulta de reclamação 762 é gerada pelo analisador de texto 360 em resposta a reclamação C2 760. A consulta de reclamação 762 pode incluir palavras-chave/frases, como determinadas com base em análise textual da reclamação C2, tal como descrito acima com relação às Figuras 3 e 6B.

[000162] O pedido de diagnóstico 710 é comunicado a partir da interface de comunicações 310 tanto para o motor de regras 340 quanto para o coletor de dados 350. A Figura 6B mostra que a reclamação C2 é incluída com o pedido de diagnóstico 710; mas, em algumas modalidades não mostradas na Figura 7B, um pedido de diagnóstico sem reclamação C2 pode ser fornecido para o motor de  regras 340 e/ou coletor de dados 350.

[000163] Na recepção da consulta de reclamação 762 e pedido de diagnóstico 710, o motor de regras 340 pode comunicar a consulta 764 com os dados de reclamação (mostrados na Figura 7B como “Comp2”) para a regras de diagnóstico e base de dados de estratégia 770 (mostrado na Figura 7B como “Diag Regras/Strat 770”) usando as técnicas descritas acima no contexto das Figuras 3, 4, e 6B. Em resposta, regras de diagnóstico e base de dados de estratégia 770 podem comunicar pedido de teste diferencial 766 relacionados ao estados da operação do DUS 102, mostrado na Figura 7B como “Estado1”. O motor de regras 640 pode gerar pedido de teste de DUS 720 para executar teste(s) para obter dados relacionados a um primeiro estado de operação Estado1 e comunicar o pedido de teste de DUS 720 para a interface de comunicações 310. A interface de comunicações 310 pode então enviar o pedido de teste de DUS 720.

[000164] Na recepção do pedido de diagnóstico 710, o coletor de dados 350 pode criar ou atualizar o perfil de DUS 776, usando as técnicas descritas acima no contexto da Figura 3. O perfil de DUS 776 pode ser armazenado em uma base de dados dos perfis de DUS, tais como os dados de perfil 772 mostrados na Figura 7B. Os dados de perfil 772 podem ser consultados para criar, atualizar, e recuperar os perfis de DUS com base em critérios relacionados a perfil, tal como descrito acima no contexto da Figura 3.

[000165] A Figura 7C mostra um cenário de exemplo 780 para processar dado relacionado ao DUS 722 e gerando responsivamente a exibição do relatório de DUS 730. Dado relacionado ao DUS 722 relacionado ao primeiro estado de operação Estado1 do DUS 102 é recebido na interface de comunicações 310. Nos cenários não mostrados na Figura 7C, dado relacionado ao DUS 732 pode incluir a reclamação C2, que pode, por sua vez, ser analisada por um analisador de texto (por exemplo, o analisador de texto 360) para determinar a consulta de reclamação. Entretanto, o cenário 780 assume que C2 já foi analisado por um analisador de texto, tal como descrito acima com relação às Figuras 3 e 7B.

[000166] Na recepção de dado relacionado ao DUS 722, o coletor de dados 350 pode atualizar o perfil de DUS 776, quando necessário, para incluir dados relacionados ao primeiro estado de operação Estado1, usando as técnicas descritas acima no contexto da Figura 3. A Figura 7C representa o perfil de DUS 776 atualizado para armazenar dados para o primeiro estado de operação Estado1 (mostrado na Figura 7C como “Estado1 Data”).

[000167] O analisador de dados 370 pode gerar uma análise diferencial por meio de comparação de dados do DUS 102 enquanto opera em um ou mais “estados de operação”. A Figura 7C mostra o analisador de dados 370 comunicando pedido de dado de Estado1 786 para os dados de perfil 772 para pedir dados relacionados ao primeiro estado de operação Estado1 DUS 102. Em resposta, o dado de perfil 772 recupera os dados relacionados ao primeiro estado de operação Estado1 a partir do perfil de DUS 776 e comunica os dados recuperados para o analisador de dados 370 através da resposta de dado de Estado1 788.

[000168] O analisador de dados 370 pode comparar dados relacionados ao primeiro estado de operação Estado1 com os dados agregados 796. Em algumas modalidades, os dados agregados 796 podem ser equivalentes aos dados agregados 672 discutidos acima no contexto das Figuras 6B e 6C. Em particular, daquelas modalidades não mostradas na Figura 7C, algum ou todo do dado agregado 796 não é armazenado no dispositivo de cliente 104; entretanto, consultas para dados agregados são enviadas através da interface de comunicações 310 para o processamento remoto.

[000169] O analisador de dados 370 pode consultar dados agregados 796 para determinar dados agregados para o estado de operação Estado1 798 (mostrado na Figura 7C como “Estado 1 Agg Data”). Na recepção de dados relacionados ao primeiro estado de operação Estado1 e dados agregados 798, o analisador de dados 370 pode gerar a análise diferencial (DA) 790.

[000170] A Figura 8A representa um fluxograma de exemplo que ilustra funções 800 para gerar a análise diferencial 790. No bloco 810, o valor de estado de operação n é ajustado em 1. No bloco 820, uma célula de grade n é determinada para o dado relacionado ao estado de operação n.

[000171] A Figura 8B mostra uma grade de exemplo 870 com célula de grade 872 que corresponde ao primeiro estado de operação Estado1 e uma célula de grade 874 que corresponde ao segundo estado de operação Estado 2. A grade 870 é uma grade bidimensional com revoluções por minuto (RPM) no eixo horizontal da grade 870 e carga no eixo vertical da grade 870.

[000172] Em algumas modalidades, carga pode ser determinada com base em uma leitura de vácuo (por exemplo, vácuo do coletor para um veículo atuando como DUS 102). Outros valores ou para o eixo horizontal e/ou o eixo vertical são também possíveis. Como tal, cada célula de grade inclui uma faixa de revoluções por minuto e uma faixa de carga. Os dados relacionados a um estado de operação podem ser examinados para determinar dados de revoluções por minuto e dados de carga. Para um determinado estado de operação, os dados de revoluções por minuto podem ser comparados com as faixas de dados de revoluções por minuto da grade para determinar uma fileira de grade para o determinado estado de operação e os dados de carga podem ser comparados com faixas de dados de carga da grade para determinar uma coluna de grade para o determinado estado de operação. A célula de grade para o determinado estado de operação é especificada pelo par determinado de fileira de grade/coluna de grade. Outras técnicas para determinar uma célula de grade para os dados relacionados a um estado de operação são também possíveis.

[000173] Como mostrado na Figura 8B, as células de grade 872 e 874 podem indicar que o estado de operação Estado1 é uma “marcha lenta” ou similar estado sem carga/baixa carga e o estado de operação Estado2 é uma “velocidade de cruzeiro” ou similar estado de carga normal na operação. Muitos outros exemplos são também possíveis, incluindo, mas não limitados a, grades com menos ou mais as células de grade e/ou grades não quadradas.

[000174] Por meio da determinação de que célula de grade n é relacionada ao estado de operação n, os dados podem ser verificados como relacionados a (ou não relacionados a) um estado de operação específico. Por exemplo, suponha que o dado D1 é recebido como sendo relacionado a um estado de operação “de marcha lenta” e que G1 é uma célula de grade determinada para D1. Por meio da determinação de que G1 é uma célula de grade relacionada ao estado de operação de “marcha lenta”, D1 pode ser verificado como sendo tomado a partir do estado de operação de “marcha lenta” específico.

[000175] Como outro exemplo, deixe D2 ser dado a partir de um teste solicitado a partir de um estado de operação de “cruzeiro”, deixe G2 ser uma célula de grade determinada para D2 usando as técnicas mencionadas acima, e suponha que G2 não se relaciona com o estado de operação de “velocidade de cruzeiro” (por exemplo, G2 se refere, entretanto, ao estado de operação de marcha lenta). Uma vez que D2 não é relacionado a uma célula de grade para o estado de operação de “velocidade de cruzeiro” específico, D1 não é verificado para estar no estado de operação de “velocidade de cruzeiro” específico.

[000176] Se for verificado que dado não está em um dado estado de operação, um pedido pode ser gerado para re-executar um teste no estado de operação apropriado. Continuando com o exemplo acima, uma vez que D2 não foi verificado como sendo a partir do estado de operação de “velocidade de cruzeiro”, outro teste pode ser solicitado para gerar dados a partir do estado de operação de “velocidade de cruzeiro”.

[000177] Em alguns casos, os dados podem ser verificados por outras técnicas diferentes do uso da célula de grade. Por exemplo, um veículo pode ser conhecido, possivelmente por meio da observação direta e/ou por meio de dados não usados para atribuir as células de grade, para estar operando em um determinado estado de operação. Por exemplo, um motorista de um veículo operando em um estado de operação de “cruzeiro” poderia afirmar que “Eu sei que eu estava dirigindo consistentemente entre 48 e 56 Km/h (30 e 35 MPH) por todo o teste”. Neste ponto, os dados podem ser verificados como sendo a partir do determinado estado de operação de “velocidade de cruzeiro”. Assim, o dado errôneo usado para atribuir dado às células de grade e subsequentes estados de operação que falharam em indicar que o veículo estava no estado de operação de “velocidade de cruzeiro” é indicativo de um problema. Consequentes estratégias de reparo para corrigir as  causas para os dados errôneos podem ser utilizadas para abordar o problema.

[000178] Retornando para a Figura 8A, no bloco 830, dado agregado n é determinado com base na célula de grade n. Por exemplo, o analisador de dados 370 pode consultar dados agregados 796 para recuperar dados relacionados ao DUS e para os dados dentro de uma célula de grade (isto é, os dados tomados com faixas de revoluções por minuto e dados de carga para a célula de grade n). Alternativamente, o analisador de dados 370 pode consultar dados agregados 796 para recuperar dados relacionados ao DUS e filtrar os dados recuperados para os dados dentro de célula de grade n, determinando assim dados agregados n. Outras técnicas para determinar dados agregados n são também possíveis.

[000179] No bloco 840, uma lista de análise diferencial (Lista de DA) n é gerada com base na comparação de dados relacionados ao estado de operação n e dados agregados n. A lista de análise diferencial pode ser gerada com base em dado relacionado ao estado de operação n e dado agregado n que difere. Técnicas de exemplo para determinar diferenças entre um valor de dado relacionado ao estado de operação n e um valor de dado agregado n incluem determinar que: um valor de dado não é o mesmo que o valor de dado agregado, o valor de dado não está dentro de uma faixa de valores de dado dos dados agregados, o valor de dado está ou acima ou abaixo de um valor limite do(s) valor(es) de dados agregados, o valor de dado não corresponde a um ou mais valores de dados agregados, cada um de um número de valores de dado não é o mesmo, dentro de uma faixa, e/ou dentro de um limite de um valor de dado agregado, computação(ões) no(s) valor(es) de dado, possivelmente incluindo valores de referência, é/são comparadas com os valores de referência, e/ou negações dessas condições.

[000180] Uma análise estatística do dado relacionado ao estado de operação n e/ou o dado agregado n pode ser usada para gerar a lista de análise diferencial n. Por exemplo, as técnicas de seleção estatística discutidas acima no contexto da figura 3 podem ser aplicadas aos dado relacionado ao estado de operação n e/ou o dado agregado n. A seleção estatística pode envolver a geração de uma ou mais estatísticas para dados agregados n e então comparação de o dado relacionado ao  estado de operação n com base nas estatísticas geradas.

[000181] Por exemplo, suponha que dados relacionados ao estado de operação n incluíram um valor de medição de Mn obtido usando um sensor Sens1. Suponha ainda que dados agregados n a partir do sensor Sens1 indicaram um valor de medição médio de AggMeanMn com um desvio padrão de AggSDMn. Então, um número de desvios padrão NSDMn a partir da média AggMeanMn para Meas1 poderia ser determinado, possivelmente usando a formula

[000182] Então, o valor de medição Meas1 poderia ser avaliado com base no número de desvios padrão NSDMn e um ou mais valores de limite. Por exemplo, suponha que as avaliações na tabela 3 abaixo foram usadas para avaliar o número de desvios padrão NSDMn:

TABELA 3

[000183] Se NSDMn está entre um limite inferior de 0 e um limite superior de 1,999, então a medição Mn pode ser avaliada como aceitável. Similarmente, se NSDMn está entre um limite inferior de 2 e um limite superior de 3,999, então a medição Mn pode ser avaliado como marginal. Se NSDMn é maior do que 4, então a medição Mn pode ser avaliada como falho.

[000184] As técnicas descritas acima para a medição de exemplo Mn e técnicas mais avançadas de análise estatística incluindo variâncias, correlações e/ou análises de componente de princípio podem ser aplicadas a variáveis múltiplas (por exemplo, a medição Mn e outras medições Mn1, Mn2.) para realizar uma “análise de múltiplas variáveis” dos dados relacionados do estado de operação n e o dado agregado. Ainda, relações entre duas ou mais variáveis do dado relacionado ao estado de operação n e ao dado agregado podem ser examinadas durante a análise de múltiplas variáveis.

[000185] Uma ou mais variáveis do dado, ou contribuidores de princípio, podem ser escolhidos, que são (a) relacionados ao estado de operação n e/ou ao dado agregado e (b) separam os relacionados ao estado de operação n e/ou ao dado agregado em diferentes categorias. Os contribuidores de princípio podem ser determinados através de operações na base de dados agregada usando técnicas para identificar um conjunto reduzido de vetores de base de princípio e mais provavelmente vetores de falha. As técnicas incluem, mas não são limitadas a, decomposição de valor singular (SVD), correlações e/ou variâncias. A projeção desses vetores para o espaço de parâmetros e variáveis reais do veículo origina as Estratégicas de Diagnóstico e prognósticos para um veículo.

[000186] Como um exemplo simplificado, suponha que se ambas as medições Mn e Mn1 fossem falhas, então uma falha do sensor Sens1 é implicada, mas Sens1 não é implicado quando Mn é falho e Mn1 não é falho. Tomando este exemplo para dimensões mais altas, considere uma situação onde existe um grande número LN de parâmetros monitorados (por exemplo, LN = 30) para um veículo. Podem estar presentes padrões dentro de reduzidos conjuntos de dados existentes, que implicarão em uma falha, e que os diferentes padrões exibiram dentro desses parâmetros de LN indicarão diferentes falhas do veículo. Através de uma singular análise de decomposição de valor, e projeções para o espaço vetorial real, subconjuntos dos parâmetros podem ser identificados para a consideração como vetores de base de princípio. Os subconjuntos dos parâmetros podem ser agrupados e monitorados para diferentes falhas. Quando o subconjunto de parâmetros exibe certas condições que podem ser monitoradas usando regras no motor de regras, uma apropriada estratégia de reparo pode ser determinada.

[000187] Análise de correlação de múltiplas variáveis pode ser usada para comparar dados relacionados ao estado de operação n e dados agregados n. Por exemplo, suponha que um vetor VAD inclui um número SN de valores de sensor de dados agregados relacionados a uma reclamação particular, incluindo valores para um ou mais componentes de princípio, e também suponha que o dado relacionado ao estado de operação n inclui um vetor VNAD de SN valores de sensor de dados não agregados a partir de um dispositivo em serviço com a reclamação particular, também incluindo valores para um ou mais componentes de princípio.

[000188] Então, uma análise de correlação pode ser realizada entre os dados nos vetores VAD e VNAD. Por exemplo, uma “correlação de padrão” ou coeficiente de correlação de produto-momento de Pearson pode ser calculado entre VAD e VNAD. O coeficiente de correlação de produto-momento de Pearson p para os vetores VAD e P _ Cov(VAD , VNAD ) VNADpode ser determinado como

onde -1 < p < +1, cov(X, Y) é a covariância de X e Y, e ó(X) é o desvio padrão de X. p indica a correlação de dependência linear a.k.a. entre os dois vetores, com p = +1 quando uma relação linear entre os vetores existe, p = -1 quando os valores VAD e VNAD estão situados em uma linha de forma que VAD aumenta quando VNAD diminui, e p = 0 quando não existe correlação linear entre VAD e VNAD.

[000189] Assim, quando p é aproximadamente ou igual a 1, pode existir uma relação linear aproximadamente ou atual entre o dado agregado VAD e os correspondentes dados de entrada a partir do veículo sob teste VNAD. Todavia, se p é maior do que uma predeterminada quantia de limite menor do que 1 (por exemplo, para uma predeterminada quantia de limite de 0,15, então p <= 0,85), uma inferência pode ser feita de que provavelmente não existe correlação linear entre VAD e VNAD. Com base nesta inferência, os dados em VAD e VNAD podem ser considerados não relacionados. Quando VAD e VNAD são determinados que não são relacionados, uma vez que o dado em VAD é agregado ou dado válido/de linha de base, outra inferência pode ser tirada, que VNAD tem dado inválido. Assim, quando p é maior do que a predeterminada quantia de limite inferior a 1, uma ou mais estratégias de reparo podem ser sugeridas para obter os dados de VNAD, incluindo valores dos componentes de princípio, mais próximos aos dados em VAD.

[000190] Outro exemplo simplificado de análise de múltiplas variáveis pode envolver a geração de um espaço de n-dimensões a partir de um conjunto de dados, tal como dado agregado, dado de linha de base, e/ou dados de referência, para um ou mais dispositivos sob teste. Cada dimensão no espaço de n-dimensões pode representar um valor de interesse de um dispositivo sob teste, tal como, mas não limitado a, valores de dado relacionado a dispositivo, valores de sensor dados a partir do dispositivo sob teste, os valores de dados de referência e/ou de linha de base, e estatísticas com base nesses valores.

[000191] Uma base de n vetores para o espaço de n-dimensões pode ser determinada; isto é, cada vetor Vbasis(i), n > i > 1, da base é linearmente independente dos outros n-1 vetores de Vbasis na base. Em algumas modalidades, o motor de regras 340 e/ou o motor de regras 440 podem utilizar o espaço de n- dimensões. Por exemplo, o motor de regras 340 e/ou o motor de regras 440 pode receber vetor(es) de entrada de n-dimensões que corespondem a uma ou mais medições tomadas a partir de um ou mais testes e realizam operações vetoriais e/ou outras operações para comparar o vetor n-dimensional de entrada com um vetores de dado de linha de base, de uma ou mais dimensões, que compartilham uma base com o vetor n-dimensional de entrada. Em particular, dados de teste podem ser mapeados no espaço vetorial de n-dimensões como um vetor n-dimensional e o motor de regras 340 e/ou o motor de regras 440 podem processar o(s) vetor(es) n- dimensional(is) de dado de linha de base e/ou o vetor n-dimensional de entrada(s).

[000192] Por exemplo, no diagnóstico de pneus, um espaço dimensional n=4, de exemplo, para pneus de um determinado par de fabricante/modelo pode incluir: pressão de pneu tp (em PSI), milhagem de pneu tm (em milhas), temperatura de pneu tt (em graus Fahrenheit), e idade do pneu ta (em anos). Então, para este exemplo, um conjunto de base de vetores Vbasis para este espaço pode ser:

Continuando com este exemplo, um vetor 4-dimensional usando o conjunto de base de exemplo de vetores para o resultado de teste indicando um pneu de 3 anos de idade tem pressão de 30 libras/polegada quadrada para um pneu com 3 anos de idade é: [30 0 0 3]T.

[000193] Dimensões no espaço vetorial n podem ser classificadas. Por exemplo, algumas dimensões podem ser classificadas como dimensões “estáticas”, enquanto outras podem ser classificadas como dimensões "dinâmicas". Uma dimensão estática é uma dimensão que não pode ser facilmente alterada durante uma sessão de reparo de um DUS, se no total. Por exemplo, a dimensão de idade de pneu ta, quando expressa em anos, não pode ser facilmente alterada durante uma sessão de reparo de um dia. Em contraste, dimensões dinâmicas podem facilmente ser alteradas durante uma sessão de reparo. Por exemplo, a dimensão de pressão de pneu tp pode ser alterar por um técnico com acesso a uma mangueira de ar, para adicionar ar e assim aumentar tp, e uma chave de fenda para liberar ar e assim diminuir tp. Como tais, medições relacionadas às dimensões estáticas podem ser usadas para classificar um ou mais componentes de um DUS, e medições relacionadas às dimensões dinâmicas podem ser ajustadas durante procedimentos de manutenção e/ou de reparo.

[000194] Uma vez quando um conjunto de valores de interesse e correspondentes vetores de base foram determinados para o espaço vetorial n- dimensional, então valores de linha de base podem ser determinados no espaço de n-dimensões, e ajustes no dispositivo sob teste, que correspondem aos valores de interesse, podem ser realizados para alinhar dados relacionados ao teste com os valores de linha de base. Continuando com os valores 4-dimensionais de pneu, suponha que dado de linha de base para um pneu de 3 anos a 70 graus Fahrenheit é: [28 tm 70 3]T, onde tm está na faixa de 10000 * ta e 20000 * ta; isto é, entre 40.000 e 80.000 milhas, e que um vetor de entrada de exemplo dos dados relacionados ao teste é: [37 50000 70 3]T. Tomando uma diferença entre o vetor de dado de linha de base e o vetor de entrada conduz a um vetor de diferença de exemplo de [-9 tm 0 0]T; assim, para obter o pneu com o dado de linha de base, a pressão de pneu deve ser reduzida por 9 PSI, como pode ser visto no valor -9 para a entrada de tp no vetor de diferença de exemplo. O motor de regras 340 e/ou o motor de regras 440 podem então disparar uma regra para prover uma estratégia ou sub- estratégia para abaixar a pressão de pneu. Por exemplo, uma estratégia ou sub- estratégia poderia ser que a pressão de pneu pode ser abaixada por pressionamento de uma chave de parafuso sobre um pino de uma haste de válvula, permitindo que ar escape, e assim abaixando a pressão do ar.

[000195] Em algumas modalidades, o motor de regras 340 e/ou o motor de regras 440 podem determinar que a dimensão tp é uma dimensão dinâmica e assim uma sub-estratégia pode ser usada para ajustar o valor do valor de tp para o DUT. Com base nesta determinação, o motor de regras 340 e/ou o motor de regras 440 podem identificar a sub-estratégia acima mencionada para abaixar pressão do pneu.

[000196] Outros limites, avaliações, esquemas de avaliação, análises de variável única e de múltiplas variáveis, vetores, bases, diferenças de dados, e/ou técnicas dos mesmos são também possíveis.

[000197] No bloco 850, uma comparação é feita entre o valor de estado de operação n e um número máximo de estados de operação (“MaxOS” na Figura 8B). Para o exemplo mostrado nas Figuras 7A-7C, o número máximo de estados de operação é dois. Se o valor de estado de operação n é maior do que, ou igual a, o número máximo de estados de operação, as funções 800 continuam no bloco 860; caso contrário, as funções 800 continuam no bloco 852.

[000198] No bloco 852, o valor de estado de operação n é incrementado por 1 e as funções 800 continuam no bloco 820.

[000199] No bloco 860, a análise diferencial 790 é determinada por combinações das listas de análise diferencial n, onde n varia de 1 até número máximo de estados de operação. As listas de análise diferencial podem ser combinadas por meio da concatenação de todas as listas, por se tomar uma união das listas de análise diferencial, por seleção de alguns, mas não todos dos dados de cada lista de análise diferencial, ou por seleção de algumas, mas não de todas as listas de análise diferencial, e/ou por meio da filtração de cada lista para diferenças comuns. Como um exemplo de filtração para diferenças comuns, suponha que n = 2 com a lista de análise diferencial 1 incluindo diferenças para os dados provenientes de três sensores: S1, S3, e S6, e a lista de análise diferencial 2 incluindo diferenças para os dados provenientes de quatro sensores: S2, S3, S6, e S8. Então, as diferenças comuns para ambas as listas de exemplo seriam os dados a partir dos sensores S3 e S6. Outras técnicas para combinar as listas de análise diferencial são também possíveis.

[000200] Em alguns cenários, o número máximo de estados de operação pode ser igual a um. Nesses cenários, a análise diferencial envolveria a comparação do bloco 840 entre dados relacionados ao estado de operação 1 e dados agregados para o estado de operação 1 e a operação de combinação do bloco 860 poderia retornar a lista de análise diferencial para o estado de operação 1. Como tal, a análise diferencial para somente um estado de operação envolve uma comparação de dados relacionados ao estado de operação e dados agregados ao estado de operação.

[000201] Assim, as funções 800 podem ser usadas para gerar uma análise diferencial por uma comparação de dados relacionados a um ou mais estados de operação e dados agregados para aqueles um ou mais estados de operação utilizando uma grade de estados de operação.

[000202] Retornando para a Figura 7C, o analisador de dados 370 pode comunicar análise diferencial 790 ao motor de regras 340. Na recepção da análise diferencial 790, o motor de regras 340 pode comunicar a consulta 792 com os dados de reclamação previamente determinados (mostrados na Figura 7C como “Comp2”) e a análise diferencial 790 para a regras de diagnóstico e base de dados de estratégia 770 (mostrado na Figura 7C como “Diag Regras/Strat 770”) usando as técnicas descritas acima no contexto das Figuras 3 e 4.

[000203] Em resposta, regras de diagnóstico e base de dados de estratégia 770 pode comunicar a estratégia 794 (mostrada na Figura 6B como “S2+’”) incluindo uma ou mais regras e sub-estratégias associadas para o motor de regras 340. Usando as técnicas descritas acima no contexto das Figuras 3, 4, e 6C, o motor de regras 340 pode determinar quais regra(s) disparar e suas sub-estratégia/sub- estratégias associadas. No cenário 780, o motor de regras 740 gera a exibição do relatório de DUS 740 que pode incluir alguma ou toda da análise diferencial 790 e/ou alguma ou todas das sub-estratégias da estratégia 794 (coletivamente mostradas na Figura 7C como “S2”) e comunica a exibição do relatório de DUS 740 para a interface de comunicação 310. A interface de comunicações 310 pode então enviar a exibição do relatório de DUS 740.

IV. OPERAÇÃO DE EXEMPLO

[000204] A Figura 9 representa um fluxograma de exemplo que ilustra as funções 900 que podem ser executadas de acordo com uma modalidade de exemplo. Por exemplo, as funções 900 podem ser executadas por um ou mais dispositivos, tais como o dispositivo de servidor 106 e/ou o dispositivo de cliente 104, descritos em detalhe acima no contexto das Figuras 1-7C.

[000205] O bloco 910 inclui receber dado relacionado ao DUS para um dispositivo em serviço. Por exemplo, o dado relacionado ao DUS poderia ser recebido em uma comunicação de dado relacionado ao DUS, tal como descrita acima em detalhe com relação a pelo menos às Figuras 6A-7C. Em algumas modalidades, o dado relacionado ao DUS inclui o dado de teste do DUS obtido a partir de um teste do DUS realizado no DUS.

[000206] O bloco 920 inclui determinar que o dado relacionado ao DUS deve ser agregado aos dados agregados. Em algumas modalidades, a determinação para agregar o dado relacionado ao DUS pode ser com base em uma classificação do dado relacionado ao DUS. A determinação para agregar o dado relacionado ao DUS é descrita acima em detalhe com relação a pelo menos às Figuras 4, 6A, 6B, e 6C.

[000207] Em algumas modalidades, determinar qual o dado relacionado ao DUS inclui: determinar um ou mais atributos do DUS a partir do dado relacionado ao DUS, selecionar dado de linha de base a partir do dado agregado com base nos um ou mais atributos do DUS, gerar uma comparação de linha de base entre os dados de teste do DUS e dado de linha de base, determinar a classificação para o dado relacionado ao DUS com base na comparação de linha de base e agregar o dado relacionado ao DUS ao dado agregado com base na classificação.

[000208] O bloco 930 inclui gerar uma comparação de dado agregado do dado relacionado ao DUS e o dado agregado. Comparações de dado relacionado ao DUS e dado agregado são descritas acima em detalhe com relação a pelo menos às Figuras 3, 4, e 6A-8B.

[000209] Em algumas modalidades, a geração da comparação de dado agregado do dado relacionado ao DUS e do dado agregado inclui: (i) determinar uma base de um ou mais vetores representando pelo menos parte do dado agregado, (ii) determinar um vetor de dado de linha de base do dado de linha de base, o vetor de dado de linha de base utilizando a base, (iii) determinar um vetor de dado de DUS do dado relacionado ao DUS, o vetor de dado de DUS utilizando a base, e (iv) determinar uma diferença de vetor entre o vetor de dado de linha de base e os vetores de dado de DUS. A geração de uma comparação de dado agregado utilizando uma base de vetor, usos para bases, e usos para diferenças vetoriais, são discutidos acima em mais detalhe pelo menos no contexto da Figura 8A.

[000210] Em algumas modalidades, a geração da comparação de dado agregado do dado relacionado ao DUS e do dado agregado inclui gerar uma correlação de padrão entre pelo menos alguns dos dados relacionados ao DUS e pelo menos alguns dos dados agregados. Correlações de padrão são discutidas acima em mais detalhe pelo menos no contexto da Figura 8A.

[000211] O bloco 940 inclui gerar um relatório de DUS baseado na comparação de dado agregado. Em algumas modalidades, o relatório de DUS pode incluir uma ou mais sub-estratégias; e em particular dessas modalidades, pelo menos uma das uma ou mais sub-estratégias pode incluir estimativa de sucesso de sub-estratégia. Relatórios de DUS, sub-estratégias, e estimativas de sucesso de sub-estratégia são descritos acima em detalhe com relação a pelo menos às Figuras 3, 4, e 6A-8B.

[000212] Em outras modalidades, o dado relacionado ao DUS inclui dados de reclamação; nessas modalidades, a geração do relatório de DUS inclui gerar o relatório de DUS com base nos dados de reclamação. Em particular, dessas modalidades, geração do relatório de DUS inclui: determinar pelo menos uma reclamação com base nos dados de reclamação, gerar uma consulta com base na pelo menos uma reclamação, consultar um motor de regras do dispositivo usando a consulta; e em resposta à consulta, receber as uma ou mais sub-estratégias. Em algumas das modalidades particulares, o dado de reclamação inclui texto de reclamação; nessas modalidades, determinar a pelo menos uma reclamação inclui: gerar uma análise textual do texto de reclamação e determinar a pelo menos uma reclamação com base na análise textual. Em outras das modalidades particulares, o dado relacionado ao DUS inclui dado de teste do DUS obtido a partir de um primeiro teste realizado no DUS; nessas modalidades, gerar a comparação de dado agregado inclui realizar a análise estatística do dados de teste do DUS e dos dados agregados, e gerar o relatório de DUS inclui gerar a consulta com base na análise estatística e na pelo menos uma reclamação. Em algumas das outras modalidades particulares, o dado relacionado ao DUS e o dado agregado, cada, compreendem dados para uma pluralidade de variáveis, e em que a realização da análise estatística compreende realizar uma análise de múltiplas variáveis dos dados para pelo menos duas variáveis da pluralidade de variáveis.

[000213] Em ainda outras modalidades, gerar o relatório de DUS com base na comparação de dado agregado pode incluir determinar pelo menos uma das uma ou mais sub-estratégias com base em uma diferença de vetores. O uso de diferenças de vetores para determinar sub-estratégias é discutido acima em mais detalhe pelo menos no contexto da Figura 8A.

[000214] Em outras modalidades, o dado relacionado ao DUS inclui dados de reclamação, e a geração da comparação de dado agregado do dado relacionado ao DUS e do dado agregado inclui: (i) determinar um reduzido conjunto de dados do dado agregado com base nos dados de reclamação, (ii) determinar um conjunto de vetores de base baseados no reduzido conjunto de dados, e (iii) identificar uma ou mais componentes de parâmetro de princípio para uma reclamação nos dados de reclamação com base em uma projeção dos vetores de base para sobre dado relacionado ao DUS. Nessas modalidades, gerar o relatório de DUS com base na comparação de dado agregado inclui: (iv) aplicar uma ou mais regras sobre os componentes de parâmetro de princípio, e (v) determinar uma sub-estratégia com base nas uma ou mais regras aplicadas. O uso de componentes de parâmetro de princípio é discutido acima em mais detalhe pelo menos no contexto da Figura 8A.

[000215] O bloco 950 inclui enviar o relatório de DUS. O envio do relatório de DUS é descrito em mais detalhe com relação a pelo menos às Figuras 3, 4, 6A, 6C, 7A, e 7C.

[000216] Em algumas modalidades, as funções 900 podem ainda incluir a geração de um pedido de diagnóstico com base na comparação de dado agregado no dispositivo, onde o pedido de diagnóstico para solicitação de dados relacionados a um segundo teste do DUS realizado no DUS. Em particular dessas modalidades, o pedido de diagnóstico inclui instruções para realizar o segundo teste do DUS.

[000217] Em ainda outras modalidades, as funções 900 podem ainda incluir receber dado relacionado ao sucesso em uma primeira sub-estratégia das uma ou mais sub-estratégias no dispositivo e ajustar a estimativa de sucesso de sub- estratégia da pelo menos a primeira sub-estratégia com base no dado relacionado ao sucesso no dispositivo.

[000218] A Figura 10 representa um fluxograma de exemplo que ilustra as funções 1000 que podem ser executadas de acordo com uma modalidade de exemplo. Por exemplo, as funções 1000 podem ser executadas por um ou mais dispositivos, tais como o dispositivo de servidor 106 e/ou o dispositivo de cliente 104 descritos em detalhe acima no contexto das Figuras 1-7C.

[000219] O bloco 1010 inclui receber um pedido de diagnóstico para um DUS. Pedidos de diagnóstico para dispositivos em serviço são descritos acima em detalhe com relação a pelo menos às Figuras 3-7C.

[000220] O bloco 1020 inclui enviar um pedido de teste de DUS para realizar um teste relacionado ao pedido de diagnóstico. Pedidos de teste do DUS e testes dos DUSs são descritos acima em detalhe com relação a pelo menos às Figuras 3, 4, e 6A-7C.

[000221] O bloco 1030 inclui receber dado relacionado ao DUS com base no teste. Receber dado relacionado ao DUS é descrito acima em detalhe com relação a pelo menos às Figuras 3, 4, e 6A-7C.

[000222] O bloco 1040 inclui enviar o dado relacionado ao DUS. Enviar dado relacionado ao DUS é descrito acima em detalhe com relação a pelo menos às Figuras 3, 4, e 6A-7C. Em algumas modalidades, o dado relacionado ao DUS é enviado através de uma interface de rede de comunicação.

[000223] O bloco 1050 inclui receber um relatório de DUS com base nenhum dado relacionado ao DUS. Relatórios de DUS são descritos acima em detalhe com relação a pelo menos às Figuras 3, 4, e 6A-7C. Em algumas modalidades, o relatório de DUS é recebido através de uma interface de rede de comunicação.

[000224] O bloco 1060 inclui gerar uma exibição de relatório de DUS do relatório de DUS. Gerar a exibição do relatório de DUS é descrita em mais detalhe com relação a pelo menos às Figuras 3, 6A, 7A, e 7C. Em algumas modalidades, a exibição do relatório de DUS é exibida através de uma interface de usuário.

[000225] A Figura 11 representa um fluxograma de exemplo que ilustra as funções 1100 que podem ser executadas de acordo com uma modalidade de exemplo. Por exemplo, as funções 1100 podem ser executadas por um ou mais dispositivos, tais como dispositivo de servidor 106 e/ou dispositivo de cliente 104 descritos em detalhe acima no contexto das Figuras 1-7C.

[000226] O bloco 1110 inclui receber um pedido de diagnóstico para diagnosticar um DUS. Pedidos de diagnóstico para dispositivos em serviço são descritos acima em detalhe com relação a pelo menos às Figuras 3-7C.

[000227] O bloco 1120 inclui determinar um teste baseado no pedido de diagnóstico. O teste pode ser relacionado a um primeiro estado de operação do DUS. Estados de operação dos dispositivos em serviço e testes relacionados àqueles estados de operação são discutidos acima em detalhe com relação a pelo menos às Figuras 3, 4, e 7A-7C. Em algumas modalidades, o teste inclui uma pluralidade de testes para o DUS.

[000228] O bloco 1130 inclui solicitação de desempenho do teste no primeiro estado de operação do DUS. Estados de operação dos dispositivos em serviço e testes naqueles estados de operação são discutidos acima em detalhe com relação a pelo menos às Figuras 3, 4, e 7A-7C.

[000229] O bloco 1140 inclui receber dado do primeiro estado de operação para o DUS com base no teste. Estados de operação dos dispositivos em serviço e dados a partir dos testes naqueles estados de operação são discutidos acima em detalhe com relação a pelo menos às Figuras 3, 4, e 7A-7C. Em algumas modalidades, o dado do primeiro estado de operação inclui dados a partir de pelo menos dois sensores associados com o DUS.

[000230] O bloco 1150 incluir verificar que o dado do primeiro estado de operação é ou não é relacionado ao primeiro estado de operação. Em algumas modalidades, verificar que o estado da primeira operação é relacionado ao primeiro estado de operação inclui: determinar uma primeira célula de grade para o dado de primeiro estado de operação, determinar um estado de operação relacionado à primeira célula de grade, e determinar que o estado de operação relacionado à primeira célula de grade é o primeiro estado de operação. Em algumas dessas modalidades, verificar que o estado da primeira operação não é relacionado ao primeiro estado de operação inclui: determinar uma primeira célula de grade para o dado de primeiro estado de operação, determinar um estado de operação relacionado à primeira célula de grade, e determinar que o estado de operação relacionado à primeira célula de grade não é o primeiro estado de operação. Verificar que dado é ou não é relacionado a um estado de operação é discutido acima em mais detalhe com relação a pelo menos a Figura 8.

[000231] No bloco 1160, uma decisão é feita de se o dado do primeiro estado de operação é relacionado ao primeiro estado de operação. Se o dado do primeiro estado de operação é relacionado ao primeiro estado de operação, o controle passa para o bloco 1170. Todavia, se o dado do primeiro estado de operação não é relacionado ao primeiro estado de operação, o controle passa para o bloco 1130.

[000232] O bloco 1170 inclui gerar uma análise diferencial do dado do primeiro estado de operação. Análises diferenciais de dados a partir de dispositivos em serviço são discutidas acima em detalhe com relação a pelo menos às Figuras 3, 4, e 7A-8B. Em algumas modalidades, gerar a análise diferencial inclui: determinar primeiro dado agregados para uma primeira célula de grade, e gerar uma primeira lista de análise diferencial para o primeiro estado de operação com base na comparação do dado do primeiro estado de operação e o primeiro dado agregado.

[000233] O bloco 1180 inclui gerar uma exibição de relatório de DUS. A exibição do relatório de DUS pode ser com base na análise diferencial. Gerar as exibições do relatório de DUS é discutido acima em detalhe com relação a pelo menos às Figuras 3, 4, e 6A-7C.

[000234] O bloco 1190 inclui enviar a exibição do relatório de DUS. Enviar as exibições do relatório de DUS é discutido acima em detalhe com relação a pelo menos às Figuras 3, 4, e 6A-7C.

V. CONCLUSÃO

[000235] Modalidades de exemplo da presente invenção foram descritas acima. Aqueles especializados na arte entenderão que alterações e modificações podem ser feitas nas modalidades descritas sem se afastar dos verdadeiros escopo e espírito da presente invenção, que é definida pelas reivindicações.

Claims (14)

1. Método, caracterizado pelo fato de que compreende: em um dispositivo, receber dado relacionado a dispositivo em serviço (DUS) para um DUS com base em um primeiro teste realizado no DUS, o dado relacionado ao DUS compreendendo dado de reclamação relacionado a uma reclamação que é devido a um primeiro componente do DUS, e dado de teste por pelo menos o primeiro teste; no dispositivo, determinar uma ou mais classificações para o dado de teste com base no dado de reclamação, em que uma ou mais classificações compreende classificações orientada por reclamação associadas com componentes do DUS, e em que determinar uma ou mais classificações compreende: classificar o dado de teste com uma primeira classificação orientada por reclamação associada com o primeiro componente do DUS; determinar se dado transmitido como parte do dado de teste é não relacionado com a reclamação; e depois de determinar que o dado transmitido como parte do dado de teste é não relacionado com a reclamação, reclassificar o dado transmitido como parte do dado de teste com uma segunda classificação orientada por reclamação que é associada com um segundo componente do DUS, em que a segunda classificação orientada por reclamação difere da primeira classificação orientada por reclamação; no dispositivo, determinar que o dado relacionado ao DUS deve ser agregado em dados agregados com base em uma ou mais classificações para o dado de teste no dispositivo, gerar uma primeira comparação de dado agregado do dado relacionado ao DUS e do dado agregado; no dispositivo, gerar um pedido de diagnóstico com base na comparação de dado agregado, o pedido de diagnóstico para solicitar dado relacionado a um segundo teste do DUS realizado no DUS; no dispositivo, receber dado relacionado ao DUS com base no segundo teste do DUS; no dispositivo, gerar um relatório de DUS com base em uma segunda comparação de dado agregado do dado relacionado ao DUS com base no segundo teste de DUS e dado agregado, o relatório de DUS compreendendo uma ou mais sub-estratégias, em que pelo menos uma das uma ou mais sub-estratégias compreende uma estimativa de sucesso de sub-estratégia; e enviar o relatório de DUS a partir do dispositivo.

2. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que determinar que o dado relacionado ao DUS deve ser agregado compreende: determinar um ou mais atributos do DUS a partir do dado relacionado ao DUS; selecionar dado de linha de base a partir do dado agregado com base nos um ou mais atributos do DUS; gerar uma comparação de linha de base entre o dado de teste do DUS e dado de linha de base; determinar a classificação para o dado relacionado ao DUS com base na comparação de linha de base; e agregar o dado relacionado ao DUS no dado agregado com base na classificação.

3. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que o pedido de diagnóstico compreende instruções para realizar o segundo teste do DUS.

4. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que gerar o relatório de DUS compreende gerar o relatório de DUS com base no dado de reclamação.

5. Método, de acordo com a reivindicação 4, caracterizado pelo fato de que gerar o relatório de DUS compreende: determinar a reclamação com base nos dados de reclamação; gerar uma consulta com base na reclamação; consultar um motor de regras do dispositivo usando a consulta; e em resposta à consulta, receber as uma ou mais sub-estratégias.

6. Método, de acordo com a reivindicação 5, caracterizado pelo fato de que o dado de reclamação compreende texto de reclamação, e em que determinar a reclamação compreende: gerar uma análise textual do texto de reclamação; e determinar a pelo menos uma reclamação com base na análise textual.

7. Método, de acordo com a reivindicação 5, caracterizado pelo fato de que o dado relacionado ao DUS compreende dado de teste do DUS obtido a partir do primeiro teste realizado no DUS, em que gerar a primeira comparação de dado agregado compreende realizar uma análise estatística do dado de teste do DUS e do dado agregado, e em que gerar o relatório de DUS compreende gerar a consulta com base na análise estatística e na pelo menos uma reclamação.

8. Método, de acordo com a reivindicação 7, caracterizado pelo fato de que o dado relacionado ao DUS e o dado agregado, cada, compreendem dados para uma pluralidade de variáveis, e em que a realização da análise estatística compreende realizar uma análise de múltiplas variáveis dos dados para pelo menos duas variáveis da pluralidade de variáveis.

9. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que compreende ainda: no dispositivo, receber dado relacionado ao sucesso em uma primeira sub-estratégia das uma ou mais sub-estratégias; e no dispositivo, ajustar a estimativa de sucesso de sub-estratégia de pelo menos a primeira sub-estratégia com base no dado relacionado ao sucesso.

10. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que gerar a comparação de dado agregado do dado relacionado ao DUS e do dado agregado compreende: determinar uma base de um ou mais vetores representando pelo menos parte do dado agregado; determinar um vetor de dado de linha de base do dado de linha de base, o vetor de dado de linha de base utilizando a base; determinar um vetor de dado de DUS do dado relacionado ao DUS, o vetor de dado de DUS utilizando a base; determinar uma diferença de vetor entre o vetor de dado de linha de base e os vetores de dado de DUS; e opcionalmente, em que gerar o relatório de DUS com base na comparação de dado agregado compreende determinar pelo menos uma das uma ou mais sub-estratégias com base na diferença de vetores.

11. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que o dado relacionado ao DUS compreende dado de reclamação, e em que gerar a comparação de dado agregado do dado relacionado ao DUS e do dado agregado compreende: determinar um reduzido conjunto de dados do dado agregado com base no dado de reclamação; determinar um conjunto de vetores de base com base no reduzido conjunto de dados; e identificar uma ou mais componentes de parâmetro de princípio para uma reclamação no dado de reclamação com base em uma projeção dos vetores de base para dado relacionado ao DUS; e em que gerar o relatório de DUS com base na comparação de dado agregado compreende: aplicar uma ou mais regras acerca dos componentes de parâmetro de princípio; e determinar uma sub-estratégia com base nas uma ou mais regras aplicadas.

12. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que gerar a comparação de dado agregado do dado relacionado ao DUS e do dado agregado compreende gerar uma correlação de padrão entre pelo menos algum do dado relacionado ao DUS e pelo menos algum do dado agregado.

13. Dispositivo de cliente, caracterizado pelo fato de que compreende: memória; um processador; e instruções armazenadas na memória que, em resposta à execução pelo processador, fazem com que o dispositivo de cliente realize o método como definido em qualquer uma das reivindicações 1 a 12 .

14. Dispositivo de cliente, de acordo com a reivindicação 13, caracterizado pelo fato de que o dispositivo de cliente compreende ainda uma interface de rede de comunicação, em que enviar o dado relacionado ao DUS compreende enviar o dado relacionado ao DUS através da interface de rede de comunicação

Images