CN107111858B - 用于汽车诊断工具数据收集和分析的系统以及方法 - Google Patents

Abstract

开发了一种用于监测车辆服务活动期间的部件使用的方法。该方法包括：利用诊断工具接收来自车辆的诊断数据；利用诊断工具接收对应于车辆中的部件的部件标识符，所述部件响应于来自诊断工具的诊断数据而在服务程序中被替换；利用诊断工具将诊断数据和部件标识符发送到服务器；以及利用服务器将部件标识符发送到与部件的制造商相关联的收听器计算设备。

Description

用于汽车诊断工具数据收集和分析的系统以及方法

相关申请的交叉引用

本申请要求享有于2013年12月23日提交的、标题为“System And Method ForAutomotive Diagnostic Tool Data Collection And Analysis”的美国临时申请No.61/920,171的优先权，由此以引用的方式将该美国临时申请的全部内容并入本文中。本申请还要求享有于2013年12月31日提交的、标题为“System And Method For Semi-AutomatedAssistance In Automotive Diagnostics”的美国临时申请No.61/922,203的优先权，由此以引用的方式将该美国临时申请的全部内容并入本文中。

技术领域

本公开内容总体上涉及汽车维修系统，更具体而言，涉及记录和分析汽车服务活动的系统。

背景技术

近年来，车辆和汽车维修的领域已经经历了在机动车辆内和识别车辆的维修问题的计算机化诊断工具中两者的计算机化系统的快速发展。现代车辆包括一个或多个计算机系统，这些计算机系统常常被称为电子控制单元(ECU)。在一些车辆中，ECU对多个系统(包括但不限于：发动机、方向盘、轮胎、传动装置、刹车、燃料供给或电池电量监测、以及气候控制系统)的操作进行控制和监测。一些车辆还包括监测车辆的操作的各个方面的多个传感器。ECU接收传感器数据并且被配置为如果传感器指示车辆中的一个或多个系统可能出现故障或在预定参数之外进行操作则生成诊断故障代码(DTC)。

许多车辆使用控制器局域网(CAN)车辆总线，以在ECU和车载传感器和车辆中的部件之间传输数据。车辆中的CAN总线、或其它等效数据网络在ECU和车辆中的各个传感器和系统之间提供通用的通信框架。另外，CAN总线或等效网络实现了ECU与外部诊断工具之间的通信。诊断工具还是具有通信端口和输入/输出设备的数字计算机，所述输入/输出设备包括显示屏幕和输入控制按钮，所述输入/输出设备将信息传达到机修工并且使机修工能够执行测试并且将命令发送到ECU。ECU和诊断工具常常使用工业标准协议，例如车载诊断(OBD)协议的版本，其包括OBD-Ⅱ协议。汽车机修工和服务专业人员都使用用于与车辆中的ECU接口连接的各种各样的数字诊断工具以诊断车辆的问题，所述车辆的问题常常由来自ECU的DTC数据指示。一些诊断工具还被配置为将命令发送到ECU，以在服务过程期间提供对车辆内的某些系统的直接控制。例如，机修工可以发送命令，以采用比可行的通过手动启动车辆更加受控的方式来测试起动电动机和发动机。

尽管汽车诊断工具现今被广泛使用，但诊断工具典型地被设计为用于与车辆单独使用。例如，抵达服务中心以进行维修的大多数车辆连接到诊断工具以帮助诊断车辆的问题并且确保在进行维修之后问题被解决。典型地，诊断结果由服务中心的一个或少数机修工读出，并且仅在特定服务访问期间被使用。因此，尽管现有的诊断工具确定地帮助进行汽车维修和修理的机修工，但现有的诊断工具不会提供关于服务中心中的操作的整个范围的较大规模的信息。例如，现有的诊断系统不会生成关于常见修理程序的频率、服务程序的持续时间、服务程序的成功程度、在修理中使用的替换部件的需求、以及其它统计数据的详细记录。可以由机修工和其它服务员工手动地记录该信息中的一些信息，但对数据的手动记录不仅消耗时间还容易出现错误。这些问题在对不同位置、具有成百上千雇员的多个服务中心进行操作的较大的服务机构中进一步复杂化。因此，对能够分析汽车服务中心中的活动的数据分析系统和诊断工具的改进将会是有益的。

公开内容

车辆维修分析系统向汽车诊断工具制造商提供具有部分公共应用程序接口(API)的服务，这使得诊断工具能够通过数据网络将诊断数据发送到维修分析服务，并且使收听器计算设备经由标准的部分公共API接收诊断数据。诊断数据识别在服务中心处接受服务的车辆的一般类型和特定类型、在车辆上进行的维修的类型、使用诊断工具进行的诊断测试程序、以及关于服务中心的活动的其它信息。收听器应用接收诊断数据并且使用诊断数据生成对一个或多个汽车服务中心中的服务活动的总结和报告，所述诊断数据是使用汽车诊断工具所生成的。

在一个实施例中，已经开发了一种用于在车辆服务活动期间监测部件使用的方法。该方法包括：利用诊断工具接收来自车辆的诊断数据；利用诊断工具接收对应于车辆中的部件的部件标识符，所述部件响应于来自诊断工具的诊断数据而在服务程序中被替换；利用诊断工具将诊断数据和部件标识符发送到服务器；以及利用服务器将部件标识符发送到与部件的制造商相关联的收听器计算设备。

在另一个实施例中，已经开发了一种用于监测车辆服务活动的方法，包括：利用多个诊断工具接收来自多个车辆的多个诊断数据；利用所述多个诊断工具将所述多个诊断数据和对应于多个服务程序的多个服务记录发送到服务器中的诊断历史数据库，所述多个服务程序是响应于来自所述多个车辆的所述多个诊断数据而在所述多个车辆上被执行；利用所述多个诊断工具中的一个诊断工具来接收来自所述多个车辆中的一个车辆的第一诊断数据；利用所述一个诊断工具将所述第一诊断数据和诊断查询发送到所述服务器；利用所述服务器来识别被存储在诊断历史数据库中的对应于所述诊断数据和所述诊断查询的服务记录；响应于所述诊断数据和所述诊断查询，利用所述服务器将所述服务记录发送给所述一个诊断工具作为解决方案；响应于来自所述服务器的所述解决方案无法解决车辆的修改问题，利用所述服务器将所述第一诊断数据和所述诊断查询发送到诊断查询收听器计算设备；利用所述诊断查询收听器计算设备在所述一个诊断工具与呼叫中心中的终端之间建立通信信道，以实现在所述一个诊断工具的用户与所述呼叫中心之间的通信，从而对所述一个车辆的与所述第一诊断数据相关的问题进行诊断；以及利用所述服务器接收来自所述呼叫中心的输入，以生成针对被存储在所述诊断历史数据库中的问题的解决方案的新的服务记录。

附图说明

图1是用于对在汽车修理和服务的过程期间所生成的汽车诊断数据进行自动检索、存储、以及分析的系统的示意图。

图2是用诊断工具生成和收集汽车诊断信息的过程的方框图。

图3是生成总结报告的过程的方框图，所述总结报告使用由诊断工具生成的数据来追踪一个或多个相关汽车服务中心的汽车服务活动。

图4是分析匿名数据以提供关于部件和服务中心处的其它部件的消耗的信息的过程的方框图，所述匿名数据对应于多个汽车服务中心的汽车服务活动。

图5是使用从诊断工具接收诊断数据的自动化系统来识别服务程序以帮助机修工解决车辆的问题的过程的方框图。

具体实施方式

出于促进对本文中所描述的实施例的原理的理解的目的，现在参考附图以及以下所写的说明书中的描述。参考并非旨在限制本主题的范围。本专利还包括对所示实施例的任何替换和修改，并且包括本文献所属领域的技术人员通常所公知的所述实施例的原理的其它应用。

如本文中所使用的，术语“客户”指的是在汽车维修期间使用诊断工具的汽车服务供应商，其将数据从诊断工具发送到在线维修分析服务，并且分析存储在在线维修分析服务中的汇总的诊断工具数据。客户的示例包括个体机修工、雇佣多个机修工的个体服务商店、以及操作多个服务中心的较大的服务机构。由于很多客户是具有多个雇员的机构，所以与客户相关联的个体被分配个体用户账户以访问在线维修分析服务从客户处所接收的数据中的一些或所有数据。

如本文中所使用的，术语“第三方”指的是出于分析的目的针对一个或多个客户对存储在在线维修分析服务中的数据进行访问的任何个体或机构。大多数第三方用户不会通过客户执行的车辆服务活动来生成诊断数据。相反，第三方分析关于一个或多个客户的活动的趋势和其它统计数字，以便例如针对该客户提高产品分布的效率。第三方的一个示例是汽车部件供应商，所述汽车部件供应商分析一个或多个客户的服务趋势以预测第三方供应商销售给客户的替换部件的未来需求。以下将更加详细地描述客户和第三方的功能。第三方和客户常常是不同的机构，但单个机构可以起到客户和第三方角色两者的作用。

如本文中所使用的，术语“收听器(listener)”指的是计算设备，所述计算设备接收原始诊断数据或者由来自在线维修分析服务的诊断数据生成的经处理的数据。在一个实施例中，与客户相关联的收听器接收来自一个或多个诊断工具的诊断数据的集合，所述诊断工具是由来自维修分析服务的客户所使用的。在一些实施例中，收听器还接收来自维护分析服务的总结和分析报告。除了客户以外，第三方执行收听器客户端应用程序，所述收听器客户端应用程序从维修分析服务接收统计数字或匿名诊断数据。在一个实施例中，每个客户可以访问来自诊断工具的诊断数据，所述诊断工具被每个客户所登记以防止一个客户接收到由其它客户生成的诊断数据。与第三方相关联的收听器能够从双方检索诊断数据，尽管诊断数据可以是匿名的或者以其它方式被编辑以限制第三方收听器的访问范围。如下所述，维修分析服务实现了能够与符合公知规范的应用程序接口(API)兼容的软件。因此，收听器客户端应用程序的不同实施例包括软件程序，所述软件程序从维修分析服务检索所存储的诊断数据或其它分析数据中的一些或全部数据以用于显示或另外的处理。

图1描绘了系统100，系统100使用由诊断工具生成的数据针对一个或多个客户监测服务中心的汽车服务活动并且为客户和诸如汽车部件供应商之类的第三方提供监测和分析服务。如本文中所使用的，术语“服务活动”指的是一个或多个机修工或其它汽车技工在机动车辆上执行的聚集操作。服务活动的示例包括诊断、例行车辆维修、车辆修理、召回服务等等。系统100包括在线诊断分析系统104、诊断工具和由图1的说明性实施例中的客户114和118操作的其它计算设备、默认的客户收听器服务124、特定客户专有的收听器服务128、第三方收听器132、诊断查询收听器156、以及呼叫中心140。出于说明性目的，图1描绘了汽车机修工160，其使用诊断工具116C从机动车辆中的电子控制单元(ECU)检索诊断数据作为车辆维修过程的部分。诊断工具116C是与系统100中的个体机修工160和客户114相关联的诊断工具116A-116C的其中之一。机修工160任选地使用电子通信设备168(例如，智能电话、平板电脑、个人计算机(PC)或其它便携式计算设备)以与诊断分析系统104和呼叫中心140进行通信从而解决车辆的维修问题。

在系统100中，用一个或多个计算设备来实施诊断分析系统104，所述计算设备被配置为操作为服务器并且通过一个或多个数据网络可操作地连接到与客户和第三方相关联的计算设备，所述数据网络包括局域网(LAN)或广域网(WAN)。在大规模的实施例中，诊断分析系统104包括多个服务器，所述服务器采用具有多个数字处理器、网络接口设备、以及数据存储设备的群集配置，所述数据存储设备包括固态或磁盘数据存储设备，其被布置在独立磁盘冗余阵列(RAID)中。在一个实施例中，服务器通过以下各项连接到数据存储设备：存储局域网(SAN)构造、网络附加存储(NAS)构造、或者使服务器能够访问所存储的数据的任何其它适合的构造。

诊断分析系统104中的数字处理器执行所存储的软件程序指令以实施：服务器，以用于与客户和第三方的计算设备的通信；数据库，以用于存储和索引从客户和第三方接收到的数据；以及执行数据分析和生成报告、总结的任选地一个或多个分析引擎；以及由客户和第三方审查的其它分析输出。在一个实施例中，维修分析服务实施了对于不同客户可自由访问的公共应用程序接口(API)。适合于在诊断分析系统104、诊断工具和收听器之间实施公共API的协议的示例包括：XML-RPC、JSON-RPC、以及SOAP协议(这些协议是网络服务协议的示例)、以及其它中间件协议(包括但不限于传统RPC、Java RMI、CORBA等)。在图1的实施例中，公共API提供了通用数据格式和接口以用于将来自一个或多个诊断工具的诊断数据从每个客户向诊断分析系统104进行传输以用于存储，诊断工具包括分别用于客户114和118的诊断工具116A-116C和120A-120C。

公共API还提供了预定的接口，以通过客户收听器实现对诊断工具数据和分析报告的检索。在一个实施例中，诊断分析系统104实施了发布-订阅(pub-sub)通信系统，在该系统中诊断分析系统104发布从用于特定客户的诊断工具接收到的诊断数据或“推送”到订阅所发布的数据流的收听器计算设备。在替代的实施例中，收听器计算设备以规律的时间间隔或者在必要时下载个体服务记录或服务记录组。如本文中所使用的，术语“服务记录”指的是在车辆上执行的服务程序期间所生成的数据。该服务记录包括但不限于：诊断工具从车辆中的ECU检索的诊断数据、来自车辆维修设施中的各个测试工具的附加诊断信息，在服务活动期间被替换或修理的部件列表、以及对机修工在服务活动期间所执行的一个或多个服务程序的描述。在一个实施例中，诊断分析系统104使用例如HTML或另一种格式化语言将诊断数据格式化以用于显示，并且收听器使用网络浏览器或其它适合的显示程序来显示诊断数据。在另一个实施例中，收听器检索诊断数据并且收听器执行本地软件应用程序以生成诊断数据的图形显示。在一些实施例中，诊断分析系统104进行附加的分析并且生成总结、图形、以及其它报告，其实基于诊断数据所生成的，但不一定直接包括诊断数据。

为了存储来自一个或多个客户的诊断数据，诊断分析系统104实施客户数据库108和诊断数据库112。客户数据库108包括认证信息，以用于从诊断工具接收数据并且用于将数据发送到与不同客户相关联的不同收听器程序。客户数据库还包括用于第三方收听器的认证信息。诊断数据库112存储从诊断工具接收到的诊断数据。客户数据库108使得客户信息与诊断数据库112中的每一个记录相关联，以识别生成每个服务记录的客户。数据库108和112实现了对来自诊断工具的诊断数据的有效存储、搜索、以及检索，以使用诊断分析系统104中的分析软件来生成报告或者发送到收听器。数据库108和112被实施为例如：相关的数据库、目标存储、层次数据库、或者具有任何其它适合的数据存储和检索格式。

在数据分析或检索期间，诊断分析系统104使用访问控制表或其它访问控制技术来确保每个收听器仅接收来自授权客户的诊断数据。另外，诊断分析系统104针对一个或多个第三方收听器检索诊断数据，并且访问控制或其它滤波器去除或改变诊断数据记录的部分以保持匿名性。例如，如果服务记录包括车辆识别号码(VIN)或在服务记录中引用的车辆的其它唯一的部件标识符，那么诊断分析系统104会从记录中去除唯一地标识的数据或将密码安全散列应用到唯一的ID以向第三方收听器提供匿名的记录。

在系统100中，每个客户在汽车维修和修理过程期间使用至少一个诊断工具。图1描绘了分别使用诊断工具116A-116C和120A-120C的两个示例性客户114和118。每个诊断工具是被配置为与大范围的车俩中的ECU接口连接的专用计算设备，以用于记录来自ECU的数据并且用于将命令发送到ECU。诊断工具包括用户输入和输出设备，包括例如：按钮、键盘、开关、以及触摸屏。诊断工具还包括存储器，其用于存储程序指令、来自车辆的所记录的诊断数据、以及在维修期间被发送到车辆中的ECU的命令和测试的记录。在一些实施例中，诊断工具包括将所记录的数据发送到诊断分析系统104的网络接口设备。

在操作期间，诊断工具连接到车辆中的ECU，以检索车辆信息、故障代码、来自车载传感器的传感器数据，并且通过生成用于ECU的命令来测试对车辆中的一个或多个系统的操作。当诊断工具连接到车辆中的ECU时，诊断工具检索车辆的VIN或者其它识别信息，其用于实现在测试下对车辆的品牌和车型的自动识别。诊断工具还记录来自车辆中的传感器的数据流以及来自车辆中的ECU的任何故障代码。一些诊断工具实施例检索以OBD-II或者其它工业标准格式的诊断数据，该其它工业标准格式能够使诊断工具可操作地连接到大范围的车辆。在系统100中，诊断工具可以由多个制造商生产。例如，在图1中，客户114使用来自第一制造商的诊断工具116A-116C，而客户118使用来自第二制造商的诊断工具120A-120C。在其它实施例中，单个客户使用来自两个或更多个制造商的诊断工具。

在图1的实施例中，诊断工具包括网络接口设备，例如有线或无线网络接口设备，这些网络接口设备实现了与在线诊断分析系统104的直接通信。诊断工具生成与车辆的一个或多个交互作用的记录，并且使用例如用于数据传输的TCP/IP协议和用于诊断分析系统104的公共API将记录发送到在线诊断分析系统104，以认证具有适当客户账户的诊断设备并且以与诊断分析系统104可兼容的格式发送所记录的数据。在替代的构造中，如果诊断工具不包括网络接口设备，那么诊断工具将诊断数据存储在内部存储器或可移除的存储器设备中。所存储的诊断数据随后被传送到PC或将诊断数据发送到诊断分析系统104的其它计算设备。在其中不可以更新现有的诊断工具以使用公共API来与诊断分析系统104进行通信的一些实施例中，所存储的诊断数据被传送到执行转换程序的PC，所述转换程序将诊断数据转换为与公共API可兼容的格式并且将数据发送到诊断分析系统104。

在一种操作模式下，诊断工具在不需要来自机修工或其它操作员的附加输入的情况下将诊断数据发送到诊断分析系统104。例如，客户114的维修工具116C包括具有所存储的认证密钥的存储器，所述认证密钥针对客户114向客户数据库108登记。被存储在维修工具116C的存储器中的认证密钥或另一唯一的标识符实现了诊断分析系统104来识别特定的诊断工具，所述特定的诊断工具产生每个服务记录以存储在诊断数据库112中。当机修工将维修工具116C连接到车辆时，维修工具116C将第一记录发送到诊断分析系统104，所述第一记录包括车辆的识别信息。在维修过程期间，维修工具116C在机修工检索故障代码时生成附加的诊断数据记录、从车辆流出数据、并且进行附加的测试。在一个实施例中，当诊断工具116C从车辆断开连接时，诊断工具116C还将服务记录发送到诊断分析系统104，以使得收听器程序能够识别诊断工具与车辆之间的每个对话的时间长度。在一个实施例中，诊断工具116C记录与每组诊断数据的生成时间相对应的时间戳，以实现对进行各测试或操作的时间的分析。在系统100中，诊断工具在不需要来自机修工的附加输入或以其它方式向机修工呈现干扰的情况下将诊断数据发送到诊断分析系统104。因此，系统100实现了在汽车服务中心的员工几乎没有负担地手动记录诊断数据的情况下的诊断数据集合。

在图1的说明性实施例中，系统100包括收听器124、128、132、以及156，收听器中的每一个收听器是至少部分地在客户电子设备(例如，PC、智能电话、或平板电脑)上执行的软件应用程序。如下所述，一些收听器实施例执行对诊断数据的计算密集分析，该计算密集分析需要超出诸如单个个人计算机(PC)之类的单个计算设备的能力的附加处理能力。在这些实施例中，客户或第三方实施具有足够的处理能力来进行分析的计算集群或其它计算系统，并且收听器客户端显示分析结果。

收听器124是“默认”的收听器程序，其被提供给客户以用于监测诊断分析系统104中的诊断数据。在一个实施例中，默认的收听器被实施为动态网络应用程序，其检索来自诊断分析系统104的诊断数据中的一些或全部数据并且显示诊断设备中的每一个设备的状态和最近的使用历史以及在一个或多个服务中心处经受服务的车辆的相对应的车辆信息。默认的收听器还提供在预定时间段(例如，先前的小时、天、周、或月)内的诊断数据的一个或多个总结报告。报告包括提供来自诊断分析系统104的信息“仪表板”概观的文本和图形，该诊断分析系统104具有实现按需对详细服务记录进行检索和显示的用户接口。例如，在一个构造中，收听器呈现关键性能指标(KPI)图形显示，该图形显示提供了对在轮班期间已经在服务中心中执行的车辆诊断测试的总数量的图形计量。对于操作多个服务中心的较大客户，默认的收听器被配置为结合针对客户所登记的不同用户账户呈现不同的数据范围。例如，收听器仅将单个服务中心中的活动的诊断数据和报告呈现给服务中心的本地管理者。本地管理者可以审查在服务中心处呈现的关于特定车辆的具体诊断的更加详细的信息。对于区域管理者，收听器呈现了总结多个服务中心的活动的缩编的报告。该缩编的报告包括关于服务中心的整体活动的汇总的统计数字，并且可以省略详细的服务记录数据除非区域管理者明确地要求来自诊断分析系统104的详细数据。

一些客户任选地实施专有的收听器，例如收听器128。专有的收听器包括实施公共API以从诊断分析系统104为客户检索诊断数据的任何软件程序，但该收听器与默认收听器124不同。专有收听器通常由客户实施以执行对诊断数据的附加分析，所述附加分析扩展了由诊断分析系统104或默认收听器124所提供的功能。一些专有的收听器被实施为插件或默认收听器应用124的其它功能扩展。在另一个实施例中，专有收听器128包括另一个计算集群，该计算集群执行对客户专用诊断数据的进一步分析并且将分析的结果呈现给客户。

第三方收听器132是软件程序，其接收一个或多个客户的诊断数据库112的诊断数据中的一些数据，并且基于诊断数据呈现报告和其它分析。如上所述，第三方被准许从一个或多个客户(例如，客户114和118)接收诊断数据的部分。例如，如果第三方是汽车部件供应商，那么从供应商购买部件的客户准许第三方供应商从诊断数据库112接收诊断数据中的一些数据。不使用第三方供应商的其它客户可以选择拒绝访问第三方供应商。诊断分析系统104实施访问控制表(ACL)或对于本领域技术人员已知的其它访问控制技术，以使得第三方收听器132能够为被准许的第三方检索诊断数据的仅一部分。在一个实施例中，供应商接收经编辑的服务记录，所述服务记录去除或修改唯一的标识符数据(例如，VIN)，而保留关于诊断过程和每个客户所进行的服务活动的详细信息。在另一个实施例中，第三方收听器132从诊断分析系统104接收总结数据。在又一个实施例中，第三方收听器132生成接口，所述接口向第三方提供涉及一个或多个客户的汽车服务活动的相关信息。

例如，向客户销售火花塞的第三方供应商接收到对服务操作(可能包括火花塞的替换)的数量的总结。第三方收听器132从诊断分析系统104接收关于多个服务程序(典型地包括对火花塞的替换)的直接诊断数据或总结诊断数据。在一个实施例中，指示汽油发动机的一个或多个汽缸中燃烧问题的诊断故障代码指示需要新的火花塞。如果诊断数据还包括在服务程序后确认发动机的燃烧的测试，那么诊断分析系统104或第三方收听器132使用一系列诊断数据来识别：服务程序可能包括替换火花塞。第三方收听器呈现针对多个客户所预估的火花塞的消耗的报告。第三方供应商继而使用该信息来增加或减少对火花塞的订购或者将火花塞存货从较低需求区域运送至较高需求区域。

在系统100中，诊断查询收听器156从与机修工相关联的诊断工具或其它电子通信设备(例如，与图1中的机修工160相关联的诊断工具116C和电子通信设备168)接收对于帮助的请求。在一些实施例中，诊断查询收听器156被实施为专有收听器128，专有收听器128基于从诊断工具接收到的诊断数据来提供附加的服务。诊断查询收听器156从诊断工具116接收搜索查询和诊断数据，例如DTC和VIN信息。在一些构造中，机修工160输入附加的搜索项或关于车辆的其它信息，以在车辆维修期间帮助诊断问题。诊断查询收听器156基于来自诊断工具116C的DTC信息从诊断历史数据库112检索维修信息。诊断查询收听器156还基于车辆的品牌、车型、以及年份缩小对诊断历史数据库112中的维修信息的搜索，其中，车辆的品牌、车型、以及年份是诊断查询收听器156根据从诊断工具116C发送的VIN进行识别的。诊断查询收听器156向诊断工具116C或电子通信设备168发送服务程序数据以便由机修工160进行审查，该服务程序数据包括例如：书面和图形服务程序指南、替换部件信息、以及其它相关的维修信息。

在一些实例中，来自诊断历史数据库112的维修信息无法使机修工160解决机械问题。机修工160使用诊断工具116C或电子通信设备168来联系呼叫中心140以获取其它帮助。在系统100中，诊断查询收听器156建立了呼叫中心140与和机修工160相关联的设备116C或168之间的通信信道。诊断查询收听器156将诊断数据(例如，DTC数据、VIN信息、车辆历史数据、以及关于先前维修过程的信息)转送到呼叫中心140。呼叫中心140接收该诊断数据，并且终端或其它适合的数据显示设备向呼叫中心140中的技术人员呈现该诊断数据。因此，系统100使得呼叫中心中的技术人员能够审查与车辆相关的诊断信息，而不需要机修工160在电话会话或其它通信对话期间手动地报告诊断信息。

图2描绘了系统100在服务过程期间生成诊断数据并且将诊断数据从诊断工具发送到维修分析服务的操作的过程200。出于说明性目的，结合图1的系统100来描述过程200。

当机修工或其它汽车服务技术人员将诊断工具连接到车辆中的ECU(方框204)时，过程200开始。如上所述，诊断工具116A-116C和120A-120C被配置为与CAN总线或其它车载数据网络接口进行接口连接，以从ECU检索诊断数据。诊断工具提取车辆固有信息(方框208)，以自动地识别车辆。例如，许多车辆中的ECU包括存储车辆的VIN的存储器，并且诊断工具使用OBD-II模式9协议或另一种适合的诊断协议来检索VIN。在图1的实施例中，诊断分析系统104存储或访问预定VIN的数据库以根据所检索的VIN来识别制造车辆的品牌、车型、以及制造年份，如果诊断工具不直接检索品牌、车型、以及制造年份的信息。

在过程200期间，诊断工具记录错误代码，例如诊断故障代码、操作条件信息、以及来自车辆中的ECU的其它诊断数据(方框212)。在维修过程期间，对错误代码的检索典型地在对维修问题的初始诊断期间或在修理之后发生，以验证修理是否是有效的。在维修的过程期间，诊断工具任选地执行测试或将命令发送到ECU，并且诊断工具将诊断测试的记录、车辆ECU的命令、以及服务程序和在车辆中作为服务程序的部分而被替换的部件的记录存储在存储器中(方框216)。例如，在服务访问期间，诊断工具116C多次检索诊断数据并且将多个测试命令发送到车辆中的ECU 166。机修工160响应于接收到DTC和来自诊断工具116C的其它诊断数据而执行一个或多个服务程序。诊断工具116C还接收部件标识符的记录，所述部件标识符对应于在服务程序期间机修工160在车辆中所替换的部件。诊断工具继续在服务访问期间为多个操作来记录诊断和测试数据。部件标识符的列表包括例如：库存单位(SKU)数量、序列号、或对应于在服务程序期间被替换的车辆中的任何部件的其它部件识别数据。例如，当机修工160响应于来自诊断工具116C的指示关于消声器的服务程序的诊断数据而替换消声器部件时，诊断工具116C发送对应于替换消声器部件的SKU。在一些实施例中，诊断工具116C或电子通信设备168包括条形码扫描器或射频识别(RFID)读取器，其扫描替换部件的SKU以在服务程序期间收集部件识别数据。

在过程200期间，诊断工具执行登录以访问诊断分析系统104(方框220)。在一个实施例中，诊断工具被配置为具有预定的登录标识符，例如诊断工具的硬件全局唯一标识符(GUID)，以及使诊断工具能够以自动的方式登录适当的客户机构所注册的账户的密码或密钥。在一些实施例中，登录过程建立了诊断工具与诊断分析系统104之间的通信信道，以使得诊断工具能够在会话期间发送多个诊断数据记录。在另一个实施例中，登陆过程包含有向维修分析服务发送每个诊断数据记录。每个诊断工具包括GUID或用于使诊断分析系统104中的诊断数据记录与特定的诊断工具相关联的另一个标识符。对应于每个诊断工具的服务记录还与操作诊断工具的客户相关联。

在完成登陆过程之后，诊断工具将服务记录发送到诊断分析系统104(方框224)，所述服务记录包括车辆固有识别数据、诊断数据、服务和修理程序记录、以及在服务程序期间车辆中被替换的任何部件的列表。如上在图1中所述，诊断工具执行软件，其将来自车辆的所记录的数据格式化成与诊断分析系统104的公共API兼容的数据格式。在过程200的一个实施例中，诊断工具执行登录并且在完成车辆服务之后发送一个或多个数据记录。在另一个实施例中，在参考方框204的处理所述的将诊断工具连接到车辆之前或期间登录发生。诊断工具继而在诊断和测试过程期间在“现场”操作模式下以最小延迟将服务记录发送到诊断分析系统104，这使得收听器能够在服务程序期间从诊断分析系统104检索服务记录以提供诊断工具所执行的活动的当前账户。

在过程200期间，诊断分析系统104存储从诊断数据库112中的诊断工具接收到的数据(方框228)。诊断分析系统104存储服务记录、替换部件标识符、以及从诊断历史数据库112中的诊断工具接收到的任何其它数据，其与诊断工具的标识符、客户数据库108中的客户账户的标识符、连接到诊断工具的车辆的VIN或其它标识符、以及诊断工具接收数据或向车辆中的ECU发送命令时的时间戳相关联。在车辆维修的过程期间，诊断工具可以将被存储在诊断数据库112中的多个记录发送到诊断分析系统104。

图3描绘了从维修分析服务接收数据的客户收听器的操作的过程300。客户收听器在多个车辆的服务期间从多个诊断工具接收服务记录和诊断数据的总结，并且用于生成对应于在单个车辆上执行的多个服务程序的车辆历史总结。出于说明性目的，参考图1的系统100来描述过程300。

在过程300期间，诊断分析系统从多个诊断工具(例如，系统100中的诊断工具116A-116C)接收多组诊断数据和服务记录(方框304)。服务信息包括诊断工具发送给诊断分析系统104的实时诊断和测试数据、以及来自诊断分析系统104的总结信息和报告。客户收听器124和128可以访问来自诊断分析系统104的总结数据和服务记录。在一个构造中，客户收听器124和128由客户114登记并且接收更新的服务信息，所述更新的服务信息是诊断分析系统104在诊断工具116A-116C的操作期间接收的，如上参考过程200所述的。每个客户使用一个或多个收听器来从诊断分析系统104接收服务信息，并且单个客户采用与诊断分析系统104接口连接的一个或多个专有收听器和默认收听器的任何组合。当诊断工具检索诊断数据并且接收多个车辆的服务记录时，多个诊断工具116A-116C生成多个服务记录。诊断工具116A-116C将诊断数据和服务记录发送到诊断分析系统104。另外，诊断工具116A-116C检索来自不同车辆的VIN，并且诊断分析系统104参考VIN数据追踪对应于单个车辆的多组诊断数据和服务记录。例如，针对连接到两个单独的服务访问的诊断设备116A-116C中的一个设备的单个车辆，诊断分析系统104生成对车辆服务历史的总结，包括对诊断数据和服务记录的总结。

诊断分析系统104使用被存储在客户数据库108中的认证数据以便使用例如密码或加密认证密钥来认证收听器124和128，并且诊断分析系统104仅将服务信息从与客户114相关联的诊断数据库112发送到默认收听器124和专有收听器128。与客户118相关联的不同组的收听器接收对应于诊断工具120A-120C的类似服务记录数据，并且客户114和118无法直接访问彼此的数据。

在过程300期间，诊断分析系统104或默认收听器124中的任一个或两者生成总结的数据并且使用服务信息来执行其它数据分析(方框308)。例如，在一个实施例中，默认收听器124用对服务记录的简短的、人可读的总结对诊断数据记录进行重定格式。例如，将包括氧气传感器的故障代码的服务记录重定格式为包括车辆的品牌、车型、和年份、对故障代码(例如，“O₂传感器错误”)的人可读的解释、以及用于生成记录的特定诊断工具的标识符的字符串。诊断工具可以与服务中心中的特定雇员或车辆车位相关联。在另一个实施例中，诊断分析系统104执行总结或分析来自一个或多个诊断工具的多个服务记录以产生对一个或多个服务中心中的活动的总结。例如，在一个实施例中，诊断分析系统104生成KPI图或其它图表的数据，该其它图表描绘在轮班的过程中连接到服务中心中的诊断工具的不同车辆的总数量。收听器124从诊断分析系统104接收总结报告数据。

在过程300期间，默认收听器124生成默认的总结用户接口或“仪表板”，这使得管理者、服务人员、以及客户的其它雇员能够审查服务信息(方框312)。在一个实施例中，仪表板接口包括被格式为人可读的文本的服务记录。仪表板显示服务记录的列表，并且默认收听器更新该列表以显示从诊断工具最近接收到的服务记录。仪表板还显示关于服务中心中的一个诊断工具、多个诊断工具的整体活动、或多个服务中心的汇总活动的图或总结报告信息。

在过程300期间，专有收听器128还从诊断分析系统104接收服务信息(方框316)。如上所述，专有收听器128是实施公共API以访问与诊断分析系统104中的客户相关联的诊断数据和其它服务信息的计算设备。专有收听器128继而执行附加的分析或采用与默认收听器124不同的方式来呈现服务数据。在一个实施例中，专有收听器128是在计算设备上执行的定制的软件程序，或者专有收听器128是存储客户的服务信息并且针对大范围的客户服务信息执行附加的分析的另一种服务器计算系统。专有收听器128处于客户(例如，客户114)的控制下，并且客户114可以配置和修改专有收听器以执行客户114感兴趣的分析，但可能无法采用与默认收听器124相同的方式生产大量客户114普遍感兴趣的报告。

图4描绘了第三方收听器访问对应于维修分析系统中的一个或多个客户的服务信息的过程400。在过程400期间，第三方收听器检索对应于服务程序中的任一种类型的服务信息，所述服务程序是机修工160和其它机修工使用来自诊断工具116A-116C和120A-120C的诊断和服务程序数据而执行的。第三方收听器还接收关于在服务和修理程序期间已经使用的部件的信息。如上所述，诊断工具(例如，诊断工具116C)接收部件数据并将部件数据发送到诊断分析系统104中的诊断历史数据库112。过程400使第三方收听器132能够而接收有关在服务程序期间使用的部件的数量和类型的汇总记录以及其它汇总报告记录,该服务程序关联于:关于接收零件的车辆的品牌、车型、和年份、执行服务操作的服务中心的汇总记录。出于说明性目的，结合图1的系统100对图4进行描述。

在图4的实施例中，过程400包括生成对应于匿名的服务记录的匿名的服务信息、汇总的部件记录、以及第三方收听器已被授权访问的客户的其它分析数据(方框404)。例如，在一个构造中，第三方收听器132被授权访问客户118而非客户114的服务信息和汇总的部件记录。第三方收听器132任选地接收关于来自客户的服务信息的元数据，例如使第三方能够识别客户服务车辆所在的服务中心的位置并且使服务信息能够与不同的服务中心相关联的地理坐标或存储数量标识符。然而，第三方收听器无法采用与客户118相同的方式直接访问诊断数据和其它服务信息。相反，诊断分析系统104在第三方收听器132接收到服务信息之前执行对服务信息的一个或多个匿名操作。例如，在一些实施例中，第三方收听器132仅从诊断分析系统104接收汇总的信息。诊断分析系统104识别涉及客户在一周的时间段内的消声器部件修理或替换的所有服务信息。第三方收听器继而仅从维修系统104接收关于消声器修理的汇总的统计数字，例如在一周时间段内被替换的消声器部件的总数量和类型。第三方收听器132与客户之间的关系可能也会影响所公开的信息类型的策略。例如，如果第三方收听器132被仅为Honda、Nissian、以及Toyota车辆品牌销售消声器部件的公司所登记，那么客户118能够指定维修分析服务仅返回上述车辆品牌而非其它车辆品牌的消声器活动的服务信息。

在数据匿名的另一个构造中，第三方收听器132被授权访问一些个体服务记录，但是诊断分析系统104去除了使第三方能够识别和追踪个体车辆的服务程序历史的VIN数据或任何其它唯一的数据，以保护使用客户来进行车辆维修的司机的隐私。如果第三方访问需要对单个车辆的识别以便例如生成追踪跨多个服务访问的单个车辆的服务程序的有效性的车辆历史总结，那么诊断分析系统104将假名过程(pseudonymization process)应用于服务信息。假名过程跨多个诊断和服务信息记录生成车辆的唯一标识符，但该唯一的标识符不包含采用与VIN相同的方式识别车辆的任何有意义的信息。因此，标识符被称为与作者的笔名具有类似功能的假名标识符。例如，在一个实施例中，诊断分析系统104在客户数据库108中生成表或其它适合的数据结构，这些表或其它适合的数据结构将随机生成的数字分配到从诊断数据收集到的每个唯一的VIN，所述诊断数据由客户的诊断工具发送到诊断分析系统104。诊断分析系统104继而在多个记录中使用相同的随机数字作为服务信息中的车辆的假名标识符，该服务信息被发送到第三方收听器132。

随着第三方收听器132接收匿名的服务信息和汇总的部件记录(方框408)，过程400继续。在一个实施例中，尽管针对诊断设备和客户收听器第三方收听器使用了与公共API不同的API来检索服务信息，但第三方收听器132使用相同的发布-订阅更新系统来从诊断分析系统104接收服务信息数据。在另一个实施例中，第三方收听器以规律的时间间隔(例如，基于小时、天、周、或月)请求大批服务信息。服务信息包括：涉及在多个车辆上执行的服务操作的类型的汇总数据；诊断分析系统106从来自车辆的VIN提取的关于车辆的汇总信息，包括车辆的品牌、车型、以及年份数据；以及诊断分析系统106从诊断工具116A-116C和120A-120C接收到的关于DTC的汇总信息。类似地，第三方收听器132接收关于在不同的时间区间内已经安装在车辆中的特定部件类型的数量的汇总信息。在一些实施例中，与部件制造商相关联的第三方收听器132仅可以访问对应于制造商所生产的部件的汇总的部件信息。例如，制造商A的第三方收听器132接收制造商A生产的刹车盘SKU A的汇总的部件记录，而制造商A不会接收来自不同制造商的另一种刹车盘SKU B的汇总的部件记录。

随着第三方收听器132分析匿名服务信息以识别客户在车辆上执行的服务的变化或趋势从而识别第三方为客户所供应的替换部件或其它材料的需求的增加或减少(方框412)，过程400继续。例如，第三方收听器分析服务信息，从而识别到需要替换车辆电池的服务测试和操作。在一种情形下，趋势示出所有客户对电池的需求统一增加或减少。在另一种情形下，趋势指示在某个地理区域中客户服务中心的车辆电池替换的增加，而替换率在另一个地理区域保持稳定或减少。在另一种情形下，趋势数据指示对于仅一个客户或仅服务中心，部件需求增加或减少。

在过程400期间，第三方收听器132识别作为需求呈增加或减少趋势的主体的部件并且生成具有识别到的部件和识别到的趋势的输出(方框416)。例如，在一个实施例中，第三方收听器生成地图的显示，其中覆盖有多个服务中心以及指示所选部件的需求变化的图形或数字图标。图形图标实现了对多个客户的部件需求趋势的有效分析。在另一个实施例中，第三方收听器132还连接到第三方供应商的库存管理系统。第三方收听器132生成输出，其呈现识别到的部件需求趋势并且呈现调节库存的整体水平或库存分布以匹配需求变化的建议。例如，如果趋势指示美国东部正在经历电池需求的增加而美国西部正在经历需求的减少，那么第三方收听器可以建议将电池库存运送到美国东部以满足客户增加的电池需求。

图5描绘了系统100的操作的过程500，该操作使机修工160能够检索修理的建议，并且如果需要的话联系呼叫中心140以接收帮助来解决该问题。在以下的讨论中，对执行功能或动作的过程500的引用指的是为执行该功能或动作由处理器对所存储的程序指令的执行。出于说明性目的，参考图1的系统100对过程500进行描述。

当机修工160或其它汽车服务技术人员将诊断工具连接到车辆中的ECU(方框204)时，过程500开始。如上所述，诊断工具116C被配置为与CAN总线或其它车载数据网络接口进行接口连接以从ECU 166检索诊断数据。一旦连接到ECU 166，诊断工具116C从ECU 166接收诊断数据并且任选地接收VIN或其它车辆信息数据(方框508)。诊断数据包括但不一定限于：DTC数据、所记录的传感器历史数据、以及来自车辆中的传感器的采用OBD-II兼容格式发送的当前数据。在一个实施例中，诊断工具116C除了使用例如OBD-II模式9协议来进行接收以外，还从ECU 166接收VIN或其它车辆识别数据。在另一个实施例中，机修工160手动地或者通过条形码扫描器输入车辆的VIN或其它识别信息，以向诊断工具116C提供VIN。

在过程500期间，机修工160基于已经从ECU接收到的DTC和其它诊断数据来输入将诊断工具116C用于诊断和服务建议的请求(方框512)。诊断查询包括车辆的诊断数据和VIN两者。诊断工具116C以自动的方式生成具有诊断数据和VIN的诊断查询。机修工160使用触摸屏接口或与诊断工具116C相关联的其它输入设备任选地输入诊断查询的附加项。在一个示例中，诊断工具116C生成包括从ECU 166接收到的两个DTC、车辆的VIN、以及手动输入的“摩擦噪声”的搜索项的诊断查询，以利用来自机修工160对车辆的观察来补充诊断数据从而帮助对问题进行诊断。

诊断分析系统104接收来自诊断工具116C的诊断查询，并且从诊断历史数据库108中的诊断信息生成查询结果(方框516)。在一个实施例中，诊断分析系统104首先查询诊断历史数据库108以识别在诊断查询中呈现的DTC和其它诊断数据的组合是否对应于数据库108中的一个或多个服务记录，数据库108中的一个或多个服务记录对应于针对车辆问题的先前所记录的解决方案，该解决方案对应于相同的诊断数据。诊断分析系统104还使用诊断查询中的VIN或其它车辆识别数据来改善搜索。诊断分析系统104使用VIN来将车辆的品牌、车型、以及年份与现有的服务记录相关联，以识别与机修工160相关的可能性最大的类似车辆的记录。如果DTC数据对应于一个或多个服务记录，但诊断历史数据库108未将DTC数据与车辆的特定VIN相关联，那么诊断分析系统104返回对应于DTC的服务记录的结果、以及识别与服务记录有关的车辆的不同品牌、车型、以及年份的标识符。

在一个实施例中，诊断分析系统104实施网络服务器，并且将来自诊断查询的结果呈现为一个或多个网页，以通过诊断工具116C或包括网络浏览器的任何其它计算设备进行显示。如果诊断查询产生多个可能的相关结果，那么诊断分析系统104生成包括简短总结信息和超链接或其它控制元素的结果，以使得机修工160能够使用网络浏览器或具有诊断工具116C的其它适合的浏览软件来审查多个结果。

在过程500期间，机修工审查来自搜索的结果并且判定服务记录中的一个记录是否描述了针对车辆修理问题的解决方案。在系统100中，诊断工具116C实施网络浏览器或使机修工160能够审查服务记录的其它软件。在另一个实施例中，机修工160使用移动设备168或诸如PC之类的另一种计算设备来对结果进行审查。

在许多实例中，来自诊断分析系统104的结果包括机修工修复车辆的问题的适合的解决方案(方框520)。机修工160继而使用诊断工具116C或移动设备168输入反馈，以更新诊断历史数据库108(方框524)。由于许多汽车修理可能花费几小时或甚至几天来完成，所以诊断分析系统104被配置为在机修工160有机会执行建议的程序并且证实程序的有效性之后接收反馈。例如，在一个实施例中，诊断工具116C在超时时间段之后向机修工160呈现反馈菜单。超时是预定的时间段(例如，24小时)或是基于期望的时间量以基于服务记录包括的时间预估来执行修理的超时。例如，诊断工具116C在预估时间过去之后向服务记录的反馈接口呈现一项工作预估的完成时间为8小时。

诊断系统104使用简化的反馈来调节对应于该反馈的服务记录的相关性排序。例如，当一个或多个机修工审查针对特定的DTC组具有推荐的程序的服务记录时，正反馈指示服务记录在修理车辆的问题方面是有用的。正反馈增加了诊断分析系统104响应于附加查询而返回服务记录的可能性，所述附加查询指定对应于服务记录的DTC或其它诊断和车辆识别数据。当响应于诊断查询而返回多个服务记录时，诊断分析系统104基于反馈对服务记录进行排序。诊断分析系统104基于排序将结果按顺序返回到来自机修工的查询，以便首先向机修工呈现具有高排序的服务记录。负反馈降低服务记录的排序。在一个构造中，如果服务记录接收到预定数量的负反馈结果而几乎不具有正反馈结果，那么诊断分析系统104从诊断查询结果删去该服务记录。

在系统100中，反馈接口包括机修工160的简化输入控制和详细输入控制。例如，简化的反馈接口包括对车辆和DTC信息的总结以及建议的诊断，以提醒机修工160先前为车辆而检索的服务记录。简化的反馈接口还为机修工160呈现是/否或多个选择问题，以得出关于服务记录是否有助于解决问题的反馈。简化的反馈接口采用标准化的方式来接收反馈输入，所述标准化方式对于机修工160需要最小时间。反馈接口还呈现详细输入接口。该详细输入接口例如是包括以下各项的形式：关于修理过程的更加详细的问题(例如，修理所需的时间、修理中所使用的部件、用于修理的工具等)；以及使机修工160能够输入对问题和修理过程的解释的文本输入。详细的反馈在以下情形下是有用的：当机修工160接收服务记录时，所述服务记录有助于机修工160诊断和修复问题；以及在机修工160想要将附加细节添加到被存储在诊断历史数据库108中的现有服务记录的情况下。

在一些实例中，机修工160使用服务记录无法解决车辆的修理问题，所述服务记录是诊断分析系统104响应于来自诊断工具116C的诊断查询而返回的(方框520)。在诊断分析系统104不识别相关服务记录的情况下或在机修工160不接收解决问题的服务记录的情况下，机修工160使用诊断工具116C或移动设备168来请求手动帮助对应于诊断查询的信息。在诊断分析系统104中，诊断查询收听器156将诊断查询信息发送给呼叫中心140中的操作员，并且将地址数据发送到与机修工160相关联的诊断工具116C或移动设备168，以在机修工160与呼叫中心140中的技术人员之间建立通信沟道(方框528)。如上所述，诊断查询收听器156在机修工160与呼叫中心140之间建立通信信道。在一个实施例中，诊断查询收听器156将通信地址数据发送到移动设备168或诊断工具116C。地址数据包括例如电话号码或统一资源定位符(URL)，其使得机修工能够建立与呼叫中心140中的人类操作员的通信信道。移动设备168和诊断工具116C使用地址数据来通过网络150建立通信信道。通信信道的示例包括电话呼叫、或文本、音频、和视频聊天会话。在图1的示例中，机修工160使用诊断工具116C或移动设备168来与呼叫中心140中的人类操作员进行通信。呼叫中心140的人类操作员自动地接收来自诊断工具116C的诊断数据，以帮助人类操作员理解并且向机修工160提供帮助。

在过程500期间，诊断分析系统104接收来自机修工160或呼叫中心140中的操作员的输入，以生成针对被存储在诊断历史数据库108中的问题的解决方案的新的服务记录(方框532)。诊断分析系统104在服务记录中自动地包括VIN和DTC以及来自诊断工具116C的其它诊断数据。当另一个机修工接收到类似的DTC数据并且请求附加的信息来诊断车辆的问题时，VIN和DTC数据使得诊断分析系统104能够检索未来的服务记录。服务记录还包括文本或其它数据，机修工160手动地输入这些数据以描述问题和用于解决问题的方法。除了文本描述以外，服务记录中的数据可以包括任何需要替换的部件的部件数量、以及有助于解释问题和用于解决问题的程序的图片或视频。在执行修理之后，机修工160还提供对执行该修理所需要的时间量的预估，这会有助于其它机修工预估问题的修理成本。

诊断分析系统104将服务记录存储在诊断历史数据库108中,该诊断历史数据库108关联于:机修工160的用户账户和任选地呼叫中心140中的帮助解决问题的操作员的账户。服务记录为操作对来自诊断分析系统104的服务记录进行检索的移动设备或诊断工具的其它机修工提供了问题的可能解决方案。

将理解的是，可以期望将上述及其它特征和功能的变型、或它们的替代方案并入许多其它不同的系统、应用或方法中。本领域技术人员随后可能做出许多当前未预见到的或未预期的替代方案、修改、变型或改进，并且其旨在由所附权利要求所包含。

Claims (6)

1.一种用于监测车辆服务活动的方法，包括：

利用多个诊断工具接收来自多个车辆的多个诊断数据；

利用所述多个诊断工具将所述多个诊断数据和对应于多个服务程序的多个服务记录发送到服务器中的诊断历史数据库，所述多个服务程序是响应于来自所述多个车辆的所述多个诊断数据而在所述多个车辆上被执行；

利用所述多个诊断工具中的一个诊断工具来接收来自所述多个车辆中的一个车辆的第一诊断数据；

利用所述一个诊断工具将所述第一诊断数据和诊断查询发送到所述服务器；

利用所述服务器来识别被存储在诊断历史数据库中的对应于所述诊断数据和所述诊断查询的服务记录；

响应于所述诊断数据和所述诊断查询，利用所述服务器将所述服务记录发送给所述一个诊断工具作为解决方案；

响应于来自所述服务器的所述解决方案无法解决车辆的修改问题，利用所述服务器将所述第一诊断数据和所述诊断查询发送到诊断查询收听器计算设备；

利用所述诊断查询收听器计算设备在所述一个诊断工具与呼叫中心中的终端之间建立通信信道，以实现在所述一个诊断工具的用户与所述呼叫中心之间的通信，从而对所述一个车辆的与所述第一诊断数据相关的问题进行诊断；以及

利用所述服务器接收来自所述呼叫中心的输入，以生成针对被存储在所述诊断历史数据库中的问题的解决方案的新的服务记录。

2.根据权利要求1所述的方法，还包括：

参考所述多个服务记录和来自所述多个诊断工具的所述多个诊断数据，利用所述服务器生成对所述多个服务程序的总结；

利用所述服务器将所述总结发送到与服务中心相关联的所述收听器计算设备，所述服务中心在所述车辆上执行至少一个服务程序；

利用所述多个诊断工具中的一个诊断工具接收来自所述多个车辆中的一个车辆的第一诊断数据；

利用所述一个诊断工具将所述第一诊断数据和对应于第一服务程序的第一服务记录发送到所述服务器，所述第一服务程序是响应于来自所述一个车辆的所述第一诊断数据而在所述一个车辆上被执行；

利用所述一个诊断工具接收来自所述一个车辆的第二诊断数据；

利用所述一个诊断工具将所述第二诊断数据和对应于第二服务程序的第二服务记录发送到所述服务器，所述第二服务程序是响应于来自所述一个车辆的所述第二诊断数据而在所述一个车辆上被执行；

参考所述第一服务记录、所述第二服务记录、所述第一诊断数据、以及所述第二诊断数据，利用所述服务器生成车辆历史总结；以及

利用所述服务器将另一个总结发送到所述收听器计算设备。

3.根据权利要求2所述的方法，还包括：

利用所述一个诊断工具接收来自所述一个车辆的车辆识别号码(VIN)；

利用所述一个诊断工具将所述VIN与所述第一诊断数据和第一服务记录一起发送到所述服务器；

利用所述一个诊断工具将所述VIN与所述第二诊断数据和第二服务记录一起发送到所述服务器；以及

参考所述VIN利用所述服务器生成所述车辆历史总结，以使得所述第一服务记录、所述第二服务记录、所述第一诊断数据、以及所述第二诊断数据与所述一个车辆相关联。

4.根据权利要求3所述的方法，还包括：

参考所述VIN利用所述服务器来识别所述车辆的品牌、车型、以及年份的至少其中之一；以及

利用所述服务器生成包括所述车辆的品牌、车型、以及年份的至少其中之一的所述车辆历史总结。

5.根据权利要求1所述的方法，还包括：

利用所述多个诊断工具接收多个车辆识别号码(VIN)，所述多个VIN中的每一个VIN对应于所述多个车辆中的一个车辆；

利用所述多个诊断工具将所述多个VIN发送到所述服务器；

参考所述多个VIN利用所述服务器来识别所述多个车辆中的每一个车辆的品牌、车型、以及年份的至少其中之一；以及

利用所述服务器生成包括所述多个车辆中的每个车辆的品牌、车型、以及年份的至少其中之一的所述多个服务程序的总结。

6.根据权利要求1所述的方法，还包括：

利用所述一个诊断工具接收来自所述一个车辆中的电子控制单元的车辆识别号码(VIN)；

利用所述一个诊断工具将所述VIN发送到所述服务器；

参考所述VIN利用所述服务器来识别所述车辆的品牌、车型、以及年份的至少其中之一；以及

利用所述服务器来识别被存储在所述诊断历史数据库中的对应于服务程序的服务记录，所述服务程序在具有所述一个车辆的品牌、车型、以及年份的至少其中之一的另一个车辆上被执行。

Images