CN117608261A - 一种车辆诊断系统 - Google Patents

Abstract

本发明公开了一种车辆诊断系统，用于对车辆进行诊断，其特征在于，包括：数据服务器；以及多个诊断装置，与数据服务器相通信连接，其中，当诊断装置通过对外接口与车辆连接时，数据服务器对车辆的基础信息、诊断装置的装置识别信息、车辆所处的诊断站点的站点信息进行验证匹配形成匹配关系，数据服务器根据匹配关系确定车辆在诊断站点需要执行的诊断操作所对应的诊断程序，诊断装置与车辆通信连接，并用于完成预定程度的诊断操作，数据服务器与诊断装置基于诊断程序共同完成全部的诊断操作。

Description

一种车辆诊断系统

技术领域

本发明涉及车辆诊断技术领域，尤其涉及一种车辆诊断系统。

背景技术

目前，在车辆的生产线中，需要在不同阶段多次执行车辆下线诊断，来保证车辆下线的稳定可靠。即，在通过如组装工序完成规定的组装等一定工序之后，配套地对车辆与这些工序有关的各项指标进行检测，若检测存在问题，则需要通过改造、修复等手段对车辆的故障进行排除直至检测通过，车辆才能继续执行下一工序或整车下线。

然而，由于不同车辆的生产工艺不同，车辆制造商需要针对诊断过程中的各个工序分别进行开发，将诊断功能分散到不同的测试设备中，并由相应工位的诊断人员执行对应的操作，从而随着生产过程保证车辆的有序诊断。

但这样仍然存在一些问题。首先，由于诊断功能分散到不同的模块中，会导致系统的集成和协调成为一项挑战，即不同模块之间的通讯和协同工作需要进行复杂的设计和调试，增加了系统的复杂性和开发成本。其次，由于现有技术中的诊断功能通常是针对特定车型或特定诊断需求设计的，如果需要对诊断功能进行调整，需要对重新设计新的诊断设备或是对旧的诊断设备返厂刷机，导致维护和升级成本高，且兼容性很差。此外，现有技术中的诊断系统通常需要较高的硬件性能支持，增加了系统的成本。

发明内容

本发明的目的就在于提供一种车辆诊断系统，解决了在车辆下线诊断过程中诊断设备和诊断程序冗余的问题，提高诊断系统的适用性和可扩展性，使得系统的维护更加方便。

本发明提供的一种车辆诊断系统，用于对车辆进行诊断，包括：数据服务器，设有复数个运行服务；以及多个诊断装置，与数据服务器相通信连接，其中，当诊断装置通过对外接口与车辆连接时，数据服务器对车辆的基础信息、诊断装置的装置识别信息、车辆所处的诊断站点的站点信息进行验证匹配形成匹配关系，数据服务器根据匹配关系确定车辆在诊断站点需要执行的诊断操作所对应的诊断程序，诊断装置与车辆通信连接，并用于完成预定程度的诊断操作，数据服务器与诊断装置基于诊断程序共同完成全部的诊断操作。

进一步地，本发明提供的车辆诊断系统，还可以具有这样的技术特征，其中，每当车辆需要执行新的诊断操作，任意一个诊断终端能够被相应诊断站点的诊断人员通过手持终端获取该诊断终端的装置识别信息，并与手持终端中存储的站点信息一并发送给数据服务器进行验证匹配，在诊断装置被诊断人员与车辆进行连接后，诊断装置通过设置在该诊断装置中的通讯协议与车辆进行通信连接，并获取该车辆的基础信息发送给数据服务器进行验证匹配得到匹配关系。

进一步地，本发明提供的车辆诊断系统，还可以具有这样的技术特征，其中，诊断装置与车辆一一对应，诊断装置通过对外接口与车辆连接发生在车辆执行第一次诊断操作前，在诊断装置与车辆进行连接后，诊断装置通过设置在该诊断装置中的通讯协议与车辆进行通信连接，并获取该车辆的基础信息发送给数据服务器进行验证匹配，每个诊断站点设有对应的识别装置，每当车辆进入诊断站点，识别装置识别出车辆的车辆识别信息，并将该车辆识别信息与诊断站点的站点信息发送给数据服务器进行验证匹配得到匹配关系。

进一步地，本发明提供的车辆诊断系统，还可以具有这样的技术特征，诊断装置中预先存储有协议栈以及用于对协议栈进行调用的预设服务，基于诊断程序与诊断装置共同完成诊断操作，包括：数据服务器通过运行服务将诊断程序发送并存储至诊断装置，并控制诊断装置执行诊断程序，诊断装置在执行过程中通过预设服务调用协议栈完成与车辆的数据交互，得到车辆反馈的诊断结果，诊断结果暂存在诊断装置中并在诊断装置与数据服务器相通信连接时发送给该数据服务器。

进一步地，本发明提供的车辆诊断系统，还可以具有这样的技术特征，诊断装置中预先存储有协议栈以及用于对协议栈进行调用的预设服务，基于诊断程序与诊断装置共同完成诊断操作，包括：数据服务器通过运行服务执行诊断程序，诊断装置在执行过程中通过预设服务调用协议栈完成数据服务器、诊断装置与车辆的数据交互，使得数据服务器得到车辆反馈的诊断结果并进行存储。

进一步地，本发明提供的车辆诊断系统，还可以具有这样的技术特征，其中，诊断操作为程序刷写操作，数据服务器根据匹配关系确定车辆在诊断站点需要执行的诊断操作所对应的诊断程序时，还根据站点信息确认需要加载至车辆的刷写文件，并根据基础信息对刷写文件进行准确性验证，数据服务器在基于诊断程序与诊断装置共同完成诊断操作之前，通过诊断装置将刷写文件刷写至车辆中。

进一步地，本发明提供的车辆诊断系统，还可以具有这样的技术特征，还包括：至少一个手持终端，由诊断人员持有，与数据服务器相通信连接，其中，手持终端具有扫码器，并存储有诊断人员所处诊断站点的站点信息，诊断装置上设有包含装置识别信息的装置标识，当诊断人员通过扫码器对装置标识进行扫描，手持终端就获取到相应的装置识别信息，并将该装置识别信息与存储的站点信息对应发送给数据服务器进行验证匹配，当数据服务器与诊断装置共同完成诊断操作后，数据服务器将相应的诊断结果根据匹配关系发送给手持终端给诊断人员确认。

进一步地，本发明提供的车辆诊断系统，还可以具有这样的技术特征，其中，手持终端具有交互界面，用于让诊断人员选择、调整和/或执行一个或多个诊断程序，当诊断操作的诊断结果表示为诊断失败时，数据服务器根据站点信息将诊断失败消息及诊断结果发送给对应的手持终端，使得诊断人员执行故障排除操作并在排除后通过手持终端选择待执行的诊断程序，数据服务器在诊断人员确认执行故障排除操作时，基于终端识别信息与装置识别信息的关联关系确定对应的诊断装置，并通过运行服务运行故障排除程序，从而通过诊断装置完成对车辆的故障排除操作。

进一步地，本发明提供的车辆诊断系统，还可以具有这样的技术特征，其中，每当数据服务器基于诊断程序与诊断装置共同完成一次诊断操作且诊断成功时，数据服务器就根据匹配关系以及预设的车辆诊断流程预测车辆下一次需要执行的诊断操作并确定相应的诊断程序，进一步将该诊断程序发送给诊断装置对替换已完成诊断的诊断程序。

进一步地，本发明提供的车辆诊断系统，还可以具有这样的技术特征，其中，诊断装置包括：核心板，核心板上设有诊断模块、缓存模块以及无线模组；接口组件，与车辆的对外接口相适配；交互组件，用于使得诊断模块与用户进行人机交互；电源组件，与接口组件、无线模组以及诊断模块电连接，用于提供电源及进行电源适配；以及扩展接口组件，与诊断模块电连接，其中，诊断模块通过接口组件与车辆电连接并用于对车辆执行诊断，缓存模块与诊断模块电连接，用于对诊断模块执行诊断产生的数据进行缓存，无线模组与诊断模块电连接，用于将诊断模块与主控制器进行连接，主控制器用于和诊断模块共同执行诊断扩展接口组件为USB接口、Type-C接口、闪存接口、Pogo Pin接口中的任意一种或多种。

发明的作用与效果

根据本发明提供的车辆诊断系统，由于通过与数据服务器通信连接的多个诊断装置连接车辆，并建立诊断装置、车辆与诊断站点之间的匹配关系，因此数据服务器可以自动地判断车辆当前所需要执行的诊断程序，并由数据服务器与诊断装置共同完成对车辆的诊断操作，因此，本方案的诊断系统不仅可以在车辆下线过程中实现自动化的诊断程序加载、运行和诊断，而且还可以基于数据服务器与诊断装置的配合，针对不同的诊断应用灵活采用不同的运行方式，如在诊断装置性能支持时通过自身来运行诊断程序，在性能不足时通过服务器来运行诊断程序，诊断装置仅保证基础服务、协议的运行，这种方式大大减少了对诊断装置性能的要求，降低了硬件成本，并且不同模块之间的通讯和协同工作相对简单，具有高灵活性和可扩展性，减少了系统的复杂性和开发成本。

本发明的其他特征和优点将在随后的说明书中阐述，并且，部分地从说明书中变得显而易见，或者通过实施本发明而了解。本发明的目的和其他优点在说明书、权利要求书以及附图中所特别指出的结构来实现和获得。

为使本发明的上述目的、特征和优点能更明显易懂，下文特举较佳实施例，并配合所附附图，作详细说明如下。

附图说明

为了更清楚地说明本发明具体实施方式或现有技术中的技术方案，下面将对具体实施方式或现有技术描述中所需要使用的附图作简单地介绍。

图1为本发明实施例提供的车辆诊断系统的结构框图。

图2为本发明实施例提供的诊断装置的结构示意图。

图3为本发明实施例提供的诊断装置的结构框图。

图4为本发明实施例提供的手持终端的结构框。

图5是本发明实施例中车辆诊断系统的诊断过程的流程图。

具体实施方式

为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合附图对本发明的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的顺序在适当情况下可以互换，以便这里描述的本发明的实施例能够以除了在这里图示或描述的那些以外的顺序实施。

此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

<实施例一>

在整车下线过程中，设有多个诊断站点，每个诊断站点设有相应的诊断人员，并负责对车辆执行不同的诊断操作。

图1为本发明实施例提供的车辆诊断系统的结构框图。

参考图1，车辆诊断系统1000包括多个诊断装置100、手持终端200以及数据服务器300。其中，诊断装置100与手持终端200均与数据服务器300相通信连接。

本实施例一中，每个诊断站点配置有若干个诊断装置100，每当有车辆进入诊断站点时，诊断人员就会将一个诊断装置100(可以是任意一个)与车辆进行连接，进一步用于后续的诊断操作。当本诊断站点的所有诊断结束后，诊断人员将诊断装置100断开与车辆的连接，用于对后续车辆进行检测。

图2为本发明实施例提供的诊断装置的结构示意图，图3为本发明实施例提供的诊断装置的结构框图。

诊断装置100用于与车辆进行连接，负责在诊断过程中与车辆进行数据交互。

参考图2及图3，诊断装置100具体包括壳体01、核心板10、接口组件20、交互组件30、电源组件40以及扩展接口组件50。其中，核心板10包括第一基板、第二基板、支撑组件、以及设置在基板上的诊断模块130、缓存模块131、无线模组150以及蓝牙模块170。

本实施例中，诊断装置100为手持式诊断终端；数据服务器300为服务器，其中存储有当前厂商在车辆下线过程中所有需要的诊断程序。诊断人员在诊断过程中携带诊断装置100，通过诊断装置100中预加载的诊断程序对车辆执行诊断。当需要执行诊断装置100中没有加载的诊断程序时，可以通过将诊断装置100与数据服务器300进行通信连接，从而通过数据服务器300与诊断装置100共同完成诊断。

核心板10用于实现诊断装置100的主要诊断功能，如向车辆发送诊断信号、整理上传诊断数据、执行诊断程序等。接下来，首先对核心板10及其相关模块做具体阐述：

两块基板用于固定以及使得诊断模块130、缓存模块131、无线模组150、接口组件20、交互组件30、电源组件40以及扩展接口组件50等硬件完成电连接。在本实施例中，第一基板、第二基板各自均为一块电路板，支撑组件则用于使得第二基板与第一基板错开设置形成双层结构。诊断模块130、缓存模块131、无线模组150、接口组件20、电源组件40均设置于第一基板靠近第二基板的一面，即在空间上位于第一基板与第二基板之间；交互组件30则设置于第二基板远离第一基板的一面，即在空间上位于第二基板与壳体01之间。

作为替代方案，核心板10也可以通过一块基板代替第一基板、第二基板以及支撑组件，所有相关模块和组件设置在一块基板。

诊断模块130与缓存模块131、无线模组150、接口组件20、交互组件30、电源组件40以及扩展接口组件50等各模块电连接，并对各模块进行控制。另外，诊断模块130能够通过接口组件20与车辆电连接，从而对车辆执行诊断。

缓存模块131包括一个在诊断模块130中设置的高速存储器以及通过闪存接口连接的闪存卡。

作为一种具体实施方式，诊断模块130为一个型号为Cortex-A7(双核)的ARM主处理器，该ARM主处理器可支持并行处理、且兼容多诊断协议。高速存储器为设置在ARM主处理器中的256M的DDR内存以及256M的Nand-flash存储器，闪存卡为SD卡，通过SD卡槽(即扩展接口组件50)与ARM主处理器连接。

如图1所示，本实施例中，诊断装置100通过无线模组150与数据服务器300相通信连接。为实现对车辆的诊断工作，数据服务器300会与诊断模块130共同完成诊断，即：诊断模块130中可以存储有不同的诊断程序并通过接口组件20对车辆完成诊断，在诊断过程中产生的诊断数据、处理结果、日志等数据会通过缓存模块131进行存储，同时，当诊断装置100通过无线模组150与数据服务器300建立连接时，还会将缓存模块131中缓存的数据上传数据服务器300，由数据服务器300对数据进行分析、统计、归档等处理。

然而，由于实际车辆诊断程序较多，因此低成本的诊断模块130可能无法存储所有的诊断程序，此时，若诊断装置100需要执行并未加载的诊断程序，诊断模块130可以与数据服务器300相连接，从数据服务器300中获取诊断程序并完成加载或替换。或者，诊断模块130也可以不加载诊断程序，通过数据服务器300来运行诊断程序，并通过诊断装置100转发诊断信号完成诊断。

在诊断过程中，具体地，因为ARM主处理器的兼容性，因此其上通过协议栈存储有多种在诊断过程中所需的通讯协议、硬件协议，因此诊断模块130可以基于这些协议与车辆完成通信并且完成对无线模组150、触摸屏193等硬件的调用。在得到诊断数据、处理结果、日志等数据时，ARM主处理器会对这些数据进行整理并归档存储，若此时无线模组150与主控制器20存在连接，还会并行地将整理后的数据上传至主控制器20。

无线模组150为WIFI模组，用于使得诊断模块130通过WIFI与主控制器20进行通信连接并完成数据的传输和接收。该WIFI模组150包括WIFI芯片151以及天线152。

其中，WIFI芯片151在基板上与诊断模块130电连接，并与第二DC-DC转换器144电连接，通过第二DC-DC转换器144的第二转换端获取工作电压保证运行。天线152与WIFI芯片151相连接，用于提供信号的收发。

在一种实际应用中，诊断模块130中预先下载好诊断程序，WIFI模组150可以在与主控制器20建立通信连接时，将诊断模块130完成车辆诊断后获取的诊断数据及相应结果上传至服务器完成归档存储。

在另一种实际应用中，诊断模块130不设有当前所需的诊断程序，此时主控制器20运行诊断程序并通过无线模组150将诊断信号发送给诊断模块130，由该诊断模块130调用各类协议与车辆通信完成诊断，诊断数据及相应结果在缓存模块131中暂存整理后并行上传给主控制器20完成存储。此时主控制器20与诊断模块130共同执行车辆诊断，因此诊断模块130在实际应用中可以灵活地适应不同诊断场景。

为实现诊断装置100的高带宽传输，整个无线模组150的带宽速率需达到600-900Mbits(优选750Mbits)，而配合该速率，诊断模块130与WIFI芯片151对接的对接带宽速率相应的需要达到400-1000Mbits(优选700Mbits)。本实施例中，WIFI芯片151支持两种频率2.4G/5G，天线152为支持基于MIMO的双天线，信号频率为80Mhz，使得5G Wifi最高支持867Mbps的传输速率。同时，缓存模块131中设置的高速存储器也能够支持高速读写，对诊断模块130的对接带宽速率进行有效支持。通过这种设计，使得诊断装置100具备高带宽的特性，配合上述并行处理的能力，可以实现诊断数据的及时下载和上传。

接口组件20部分安装与壳体01上、部分安装与基板上，用于连接车辆的对外接口。该接口组件20包括连接器接口121、两路适配用接口122(1)、122(2)以及自动切换开关123。

其中，连接器接口121与车辆的对外接口的型号相匹配，例如是OBD接口或其他工业级连接器接口，该连接器接口121安装在壳体01上，从而便于诊断人员将诊断装置100与车辆进行连接。适配用接口122则于车辆对外接口所支持的接口协议相对应，该适配用接口122与自动切换开关123安装在基板上，两路适配用接口122(1)、122(2)分别与诊断模块130电连接。

作为一种具体的实施方式，适配用接口122分别为CAN接口、ETH接口，可以理解的是，适配用接口可以根据实际市场上各类车型所支持的接口协议对应设置，例如，在其他实施方式中，适配用接口122还可以是CANFD接口或者其他能够支持车辆诊断的接口，且可以根据需要设置三路或者更多路的适配用接口122。

自动切换开关123用于在连接器接口121与车辆的对外接口连接时，根据该对外接口所对应的接口协议自动切换相应的适配用接口122。具体地，自动切换开关123为一个自动切换开关矩阵，设置在连接器接口121与适配用接口122之间，可自动适配不同的OBD接口针脚定义。当接收到车辆对外接口输出的信号类型时，自动切换开关123就根据该信号类型切换匹配对应的适配用接口122。

本实施例中，由于不同的接口类型在OBD接口中的针脚定义不同，即在车辆连接时，不同的接口协议会通过不同的针脚发送电信号给连接器接口121，因此自动切换开关123可以根据电信号所对应的针脚数判断当前接口协议的类型，从而切换匹配对应的适配用接口122。

在实际情况中，由于车辆的安全访问机制，在执行诊断操作时往往必须通过车辆上特定的物理访问接口才能传输并接收诊断所需的数据，并且不同车辆所支持的接口类型也可能不同，会在定制诊断设备的过程中造成一定麻烦。因此本方案通过预设市场上车辆常用的接口类型，并通过自动切换开关123完成对不同车辆的自动适配，提升了诊断装置100在车辆下线诊断过车中的通用性。

交互组件30安装在壳体上，用于使得诊断模块130与用户进行人机交互。

作为一种具体实施方式，如图2所示，交互组件30包括四个提示灯191以及一个按钮192，相应地，壳体正面开设有与提示灯191以及按钮192的数量和形状相适配的五个安装孔。

提示灯191用于对诊断模块130的诊断程序执行结果或者其他结果进行提示。作为一种具体实施方式，各提示灯191可以分别是表示诊断装置100的充电状态的充电提示灯、表示诊断程序是否正在运行的运行提示灯、表示接口组件20是否与车辆完成连接的车辆连接提示灯、表示WIFI连接状态的WIFI提示灯等。

按键192则用于让诊断人员对诊断装置100进行简单控制，作为一种具体实施方式，各按键192可以是用于开关诊断装置100的开关机键，以及其他与诊断程序相适配的功能键，如启动诊断、暂停诊断等。

上述提示灯191以及按钮192固定在第二基板上，分别与诊断模块130进行电连接，并通过壳体上的安装孔露出至壳体外部使得用户可以查看提示灯状态或者对按键进行操作。

本实施例交互组件20的结构舍弃了复杂的人机交互部分，仅通过简单按钮操作以及提示灯向诊断人员提示当前运行状态，使得诊断人员在实际操作过程中，仅需要通过按钮启动车辆诊断装置100，并将其连接至车辆的对外接口即可开始诊断，大大简化了诊断人员的诊断操作，在便携的基础上，还具备易用性。

可以理解的是，提示灯191以及按键192的数量、设置的位置以及对应的功能也可以根据实际开发需要进行调整，本实施例中对此不作限制。

另外，在其他实施状态中，交互组件30还可以包括扬声器以及触摸屏。扬声器可以通过播放音频的方式对诊断人员进行提示；触摸屏可以是触控LCD屏幕，根据诊断模块130中所存储的诊断程序显示相应界面并使得诊断人员可以执行相关操作。

电源组件40与接口组件20、无线模组150以及诊断模块130分别电连接，用于提供电源及进行电源适配。

具体地，电源组件40包括依次串联的保护组件141、第一DC-DC转换器142、电源开关143以及第二DC-DC转换器144，还包括与第一DC-DC转换器142电连接的电池模块，该电池模块包括电池管理器145以及电池146。

其中，保护组件141用于对车辆通过接口组件20输出的电源进行保护，具有保险丝以及瞬态二极管(TVS)，当车辆错误地输出大量电压时，保护组件141可以及时保护诊断装置100不受损坏。

第一DC-DC转换器142的第一转换端与保护组件141电连接、第二转换端通过电源开关143与第二DC-DC转换器144的第一转换端电连接。本实施例中，第一DC-DC转换器142用于对12V与5V的电压进行相互转化，其第一转换端的电压为12V，第二转换端的电压为5V。

电源开关143用于控制开断车辆以及电池146对诊断模块130的供电，实现整个诊断装置100的运行开关。

第二DC-DC转换器144的第二转换端与诊断模块130以及Wifi模组150电连接。本实施例中，第二DC-DC转换器144用于对5V与3.3V的电压进行相互转化，其第一转换端的电压为5V，第二转换端的电压为3.3V。

本实施例中，由于设有电池146，并通过电池管理器145用于对电池146的电量输出进行管理和控制，因此在未与车辆连接时，诊断装置100也可以正常运行，便于诊断人员携带使用。

扩展接口组件50固定在壳体上，并与诊断模块130电连接以实现对应功能。

作为一种具体实施方式，扩展接口组件50为Pogo Pin接口161以及闪存接口162。

Pogo Pin接口161设置在壳体的侧面，可以同时支持数据传输及充电。

闪存接口162为SD卡槽，用于插入SD卡并使得诊断模块130能够对SD卡进行读取，从而使得SD卡成为缓存模块131。

在其他实施方式中，扩展接口组件也可以是USB接口、Type-C接口中的任意一种，或是USB接口、Type-C接口、Pogo Pin接口以及SD接口中多种任意组合。具体地：

USB接口用于连接U盘，从而使得能够读取U盘中的内容。应用在车辆诊断装置上时，U盘可以用于安装系统镜像文件，从而使得需要对诊断模块130的系统进行安装、更新或者刷写时，能够通过U盘完成系统的刷写及安装。另外，USB接口的连接也可以用于对诊断模块130的诊断数据及相应结果进行数据导出工作。

Type-C接口与Pogo Pin接口的作用类似，可以同时支持数据传输及充电。

蓝牙模块170用于使得诊断模块130能够与诊断人员持有的具备蓝牙功能的配置设备相通信。在实际应用中，基于蓝牙模块170，还能够让诊断人员通过该蓝牙连接来对诊断模块130的配置信息进行更改，例如对WIFI的ssid、IP地址进行配置或更改等。

本实施例中，核心板10的整体电压在5V以下，功耗控制在1.5W至2.0W之间，整个诊断装置100的功耗控制在3W至5W之间，因此核心板10还具有低功耗特性，可以有效应对长时间的车辆诊断需求。

还需说明的是，在具体实施过程中，诊断装置100还可以包括实现正常运行所必需的其他组件。此外，本领域的技术人员可以理解的是，上述诊断装置100也可以仅包含实现本申请实施例方案所必需的组件，而不必包含图中所示的全部组件。

以上为诊断装置100的具体介绍，接下来对手持终端200做具体阐述：

图4为本发明实施例提供的手持终端的结构框图。参考图4，手持终端200包括核心装置60、操作装置70、扫码器80以及交互组件90。

其中，核心装置60具体包括第一壳体、核心板10’、接口模块62、散热模块63、电源模块64以及扩展接口模块65。

操作装置70至少具有第二壳体、操作控制模块72以及显示器73。

其中，显示器73设置在第二壳体面向用户的一面。第一壳体具有开口的一面，该开口的一面和第二壳体上与显示器73相对的一面配合连接，从而实现核心装置60和操作装置70在结构上的固定连接。

本实施例中，手持终端200为手持式诊断终端；核心装置60中存储有与车辆通信所必要的驱动、协议及服务，操作装置70中存储有当前厂商在车辆下线过程中所需要的诊断程序以及能够与诊断人员进行人机交互所必要的操作系统。

在第一种使用场景中，诊断人员可以在诊断过程中携带手持终端200，在将车辆诊断内设备与车辆连接后，通过操作装置70运行其中的诊断程序，由核心装置60将诊断程序运行时产生的信号与车辆进行通信交互，最终由操作装置70将诊断数据及结果展示给诊断人员，实现操作装置70与核心装置60对车辆完成共同诊断。

在第二种使用场景中，当车辆诊断过程出现问题(如车辆诊断不通过)，诊断人员还可以通过操作装置70对诊断程序或者车辆进行调试，在此过程中同样由核心装置60完成与车辆的通信交互。

核心板10’用于实现核心装置60的主要诊断功能，如向车辆发送诊断信号、整理上传诊断数据等。该核心板10’包括基板，以及设置在基板上的诊断模块66、缓存模块67以及无线模组68。

本实施例中，基板是一块电路板，用于固定以及使得诊断模块66、缓存模块67、无线模组68、接口模块62、散热模块63、电源模块64以及扩展接口模块65等硬件完成电连接。

上述手持终端200中的诊断模块66、缓存模块67、无线模组68、接口模块62、散热模块63、电源模块64以及扩展接口模块65，与诊断装置100中的诊断模块130、缓存模块131、无线模组150、接口组件20、电源组件40以及扩展接口组件50功能上类似，因此不多做赘述。

散热模块63设置在第一壳体内，并位于核心板10’的一侧，用于对操作装置70、核心板10’、电源模块64进行散热。位于核心板10’的另一侧的第一壳体上开设有出风口，使得风在第一壳体内部循环保证散热性能。

以上为核心装置60的具体介绍，接下来描述操作装置70：

操作控制模块72用于控制手持终端200中各硬件的运行，以及用于和诊断模块66共同执行诊断。

作为一种实施形态，操作控制模块72为Intel移动平台处理器，可支持带win10操作系统，并在手持终端200中配置有8G内存、256GB存储，显示器73为该Intel处理器支持的显示屏。在实际使用时，手持终端200可以是一个平板电脑，并安装有操作系统(即第二操作系统层2006)，能够实现与诊断人员的人机交互，便于诊断人员对诊断程序进行调试和执行。

本实施例中，诊断模块66仅负责与车辆通讯，Intel移动平台处理器负责与上下游系统的连接、数据存储和及时调试，因此，诊断模块66可以采用较低成本的芯片，如本实施例中诊断模块66采用双核的ARM主处理器，处理性能600Mhz-900Mhz(优选700Mhz)；而手持终端200虽然有必要采用高性能的处理器，如本实施例中操作控制模块72采用多核的Intel移动平台处理器，处理性能2.0Ghz-2.5Ghz(优选2.2Ghz)，但该手持终端200可以采购现有的计算机设备作为手持终端200，并通过现有的操作系统来支持运行诊断程序及人机交互，适配车辆的额外开发部分可以集中在低成本的诊断模块66上。最终，低成本的核心装置与高性能的操作装置相互配合完成针对车辆的诊断操作，因此本方案的手持终端200在成本降低的基础上，仍然具有高性能的车辆诊断能力。

作为一种实施形态，本实施例的手持终端200还设有扫码器80。

扫码器80包括设置在第二壳体上的扫码按键以及扫描指示灯，两者均与手持终端200电连接。在实际应用中，车辆及其他车辆诊断设备上会设有二维码或条形码，诊断人员可以将扫描指示灯对准待扫描的位置，并按下扫码按键使得扫描指示灯执行扫描，进而使得操作控制模块72获取二维码或条形码中存储的数据进行后续处理。

交互组件90为手持终端200在使用过程中所需要的提示灯、按键、扬声器等部件。

作为一种具体实施方式，本实施例中交互组件90为3个设置在核心装置60上的提示灯、3个设置在核心装置60上的按键、以及4个设置在手持终端200上的按键。具体地，

3个设置在核心装置60上的提示灯分别设置在第一壳体110的侧面，分别是表示手持终端200的充电状态的充电提示灯、表示诊断程序是否正在运行的运行提示灯、表示接口模块20是否与车辆完成连接的车辆连接提示灯。

3个设置在核心装置60上的按键分别设置在第一壳体的侧面，分别是用于启停诊断的诊断按键、用于从车辆获取诊断数据的车辆信息获取按键以及对核心装置60进行硬启动的硬启动按键。

4个设置在手持终端200上的按键分别设置在第二壳体的侧边，分别是用于增大和减小音量的两个音量调节按键、用于开关手持终端200的开关机键以及针对手持终端200的Win键。

启停诊断的诊断按键、用于从车辆获取诊断数据的车辆信息获取按键以及对核心装置60进行硬启动的硬启动按键。

本实施例中，第一壳体以及第二壳体上设有为适配交互组件90安装的安装孔。

需要说明的是，尽管上述交互组件90的提示灯以及按钮均设置在第一壳体或第二壳体侧边，但在实际应用中，提示灯以及按钮也可以设置在壳体的正面或者背面等其他便于用户观察和使用的位置，本实施例对此不作限制。并且，可以理解的是，提示灯以及按钮的数量以及对应的功能也可以根据实际开发需要进行调整，本实施例中对此亦不作限制。

另外，在其他实施状态中，交互组件90还可以包括扬声器，从而通过播放音频的方式对诊断人员进行提示。

还需说明的是，在具体实施过程中，手持终端200还可以包括实现正常运行所必需的其他组件。此外，本领域的技术人员可以理解的是，上述手持终端200也可以仅包含实现本申请实施例方案所必需的组件，而不必包含图中所示的全部组件。

以上为手持终端200的具体介绍。

数据服务器300用于对所有的诊断装置100以及手持终端200进行管理，并负责对诊断数据和诊断结果进行存储。

数据服务器300设有复数个运行服务，并存储有所有的诊断程序。其中，每个诊断程序与诊断站点的站点信息在数据服务器300中预先存在匹配关系。

本实施例中，核心装置60、手持终端200以及数据服务器300通过特定的软件架构来完成车辆诊断。接下来，将针对该软件架构做具体介绍。

车辆诊断软件架构2000包括操作系统层2001、协议层2002、中间层2003以及应用层2004。

操作系统层2001包括操作系统以及与诊断系统硬件1001相对应的驱动(诊断系统硬件1001即诊断装置100中的无线模组150、接口模块20、散热模块30、电源模块40、扩展接口模块50等硬件，或是核心装置60中的扫码器80、交互组件90、接口模块62、散热模块63、电源模块64以及扩展接口模块65等硬件)。

本实施例中，操作系统及硬件驱动程序至少用于提供原始硬件驱动、进程调用、内存管理等功能，协议层2002、中间层2003以及应用层2004设置在操作系统上。

协议层2002包括用于对硬件进行驱动的硬件协议栈、以及用于通信的网络协议栈。

本实施例中，硬件协议栈设置有多个与诊断系统硬件1001相对应的硬件驱动协议，例如与提示灯相对应的灯驱动协议；网络协议栈包括以太网协议栈和CAN协议栈，其中，网络协议栈包括标准TCP/IP协议、数据服务器通讯心跳协议等，CAN协议栈包括各类诊断通讯协议(如CAN协议、ETH协议)等。另外，在实际应用中，协议层2002还可以包括一些其他辅助协议。

中间层2003包括进程调用管理服务以及进程通信管理服务。

进程调用管理服务用于对应用层2004中的应用程序以及预设服务进行调用管理，以及用于对预设服务和各协议进行失效检测和纠正。

进程通信管理服务用于对应用层2004、协议层2002、操作系统层2001之间的所有进程间的通信进行管理。

本实施例中，操作系统层2001、协议层2002、中间层2003设置在诊断装置100以及手持终端200的核心装置60上，应用层2004设置在手持终端200的操作装置70以及数据服务器300上。中间层2003的进程通信管理服务可以通过远程调用服务(如RPC服务)来跨设备地管理进程间通信。

作为第一种实施形态，数据服务器300通过运行服务来执行诊断程序，该诊断程序在运行时产生的硬件调用请求及其他相关请求通过远程调用服务发送给诊断装置100的进程通信管理服务，随后进程调用管理服务根据该请求确定对应的预设服务，并通过该预设服务调用相应的协议完成数据服务器300、诊断装置100与车辆的数据交互，并在后续通信过程中将车辆反馈的诊断数据及诊断结果发送给数据服务器300进行存储。这样就实现了数据服务器300与诊断装置100共同完成对车辆的诊断操作。

类似地，当通过手持终端200的操作装置70运行诊断程序时，硬件调用请求通过远程调用服务发送给核心装置60并进行后续处理，从而实现操作装置70与核心装置60共同完成对车辆的诊断操作。

作为第二种实施形态，数据服务器300在确定待执行的诊断程序后，还可以将该诊断程序传输至诊断装置100中(相当于应用层2004部分地设置在诊断装置100中)，并在接下来由诊断装置100执行诊断程序。在这种实施形态中，诊断装置100的进程通信管理服务可以直接将诊断程序的硬件调用请求及其他相关请求发送给进程调用管理服务，随后进程调用管理服务根据该请求确定对应的预设服务，并通过该预设服务调用相应的协议完成诊断装置100与车辆的数据交互，并在后续通信过程中将车辆反馈的诊断数据及诊断结果进行暂存，直到诊断装置100与数据服务器300进行通信连接时将诊断数据及诊断结果发送给数据服务器300进行存储。这样也可以实现数据服务器300与诊断装置100共同完成对车辆的诊断操作。

在上述第一种实施形态中，诊断装置100仅负责与车辆的通讯交互，数据服务器200负责了诊断程序的运行以及后续诊断结果的收集分析，而在第二种实施形态钟，诊断装置100负责了诊断程序的运行以及与车辆的通讯交互，数据服务器200则负责确定诊断程序以及后续诊断结果的收集分析。由此可以看出，车辆诊断系统1000下的诊断装置100负责预定程度的诊断操作，会由数据服务器200与诊断装置100共同完成全部的诊断操作。诊断装置100执行诊断操作的程度会依据诊断装置100的运算性能、以及车辆下线诊断的流程而定。

应用层2004包括至少一个诊断程序以及多种预设服务。

不同的诊断程序用于对车辆执行不同的诊断操作，例如雷达标定、车窗标定、摄像头标定、软件刷写、ECU测试等。

预设服务包括用于对所述网络协议栈以及所述CAN协议栈进行调用的车辆通讯服务以及各种与硬件协议的类型相对应的服务，这些服务用于对相应类型的硬件协议进行统一调用，进一步完成对硬件的控制，从而实现诊断程序所需要实现的功能。本实施例中，每个预设服务独占一个进程。

在实际情况中，由于通过应用层2004对硬件服务直接进行访问会存在一定的冲突，例如，当诊断程序对某一硬件进行占用时，会导致其他诊断程序对该硬件的访问失败，因此需要通过预设服务来进行统一调用，解决应用访问的冲突问题。

本实施例中，所有诊断程序均设置数据服务器300与操作装置70中，预设服务被设置在诊断终端100以及操作装置70中(相当于应用层2004全部地设置在操作装置70中。数据服务器300可以根据车辆的状态以及所在的诊断站点自动判断待执行的诊断程序；而在手持终端200上，诊断人员也可以通过操作装置70的显示屏选定并执行需要执行的诊断程序。

需要说明的是，虽然本实施例中说明了应用层2004可以全部或部分地设置在诊断装置100、操作装置70以及数据服务器300中，但在实际应用中，应用层2004还可以全部或部分地设置核心装置60或是其他计算设备上。例如，诊断程序和部分预设服务设置在操作装置70中、另一部分预设服务设置在诊断装置60中，或者诊断程序及预设服务全部设置在数据服务器300中等等，本车辆诊断软件架构2000所设计的应用层2004可以根据硬件条件灵活地设置在不同平台中。

作为一种实施形态，当车辆诊断设备1000与车辆进行连接时，进程调用管理服务会调用车辆通讯服务与车辆进行通讯并从CAN协议栈中确定出与当前车辆相适配的通讯协议，进一步在后续与车辆的通讯过程中均采用该适配的通讯协议完成数据交换。

图5是本发明实施例中车辆诊断系统的诊断过程的流程图。

参考图5，为便于说明，接下来以针对整车下线检测中，对车辆的ECU进行软件刷写操作为例，对车辆诊断系统的诊断过程作详细介绍。

步骤S1，当诊断装置100通过接口组件20与车辆连接时，数据服务器300对车辆的基础信息、诊断装置的装置识别信息、车辆所处的诊断站点的站点信息进行验证匹配形成匹配关系，。

作为一种实施形态，诊断装置100通过对与车辆进行连接，并通过协议层2002与车辆建立通讯后，就会从车辆获取到其基础信息，包括车辆VIN码(相当于车辆识别号)、车辆参数、系统软件版本等信息。接下来，这些数据通过协议层2002解包，并与当前诊断装置100的装置识别信息一起，通过WIFI模组150发送给数据服务器300。

而在诊断人员将诊断装置100与车辆进行连接时，需要通过手持终端200的扫码器80对诊断装置100进行扫码(诊断装置100上设有包含装置识别信息的装置标识，如二维码)，此时，手持终端200就能够获取到诊断装置100的装置识别信息，并进一步将其与手持终端200中存储的当前诊断站点的站点信息一起发送给数据服务器300。

通过上述操作，数据服务器300即可建立诊断装置100、诊断站点以及车辆之间的匹配关系。

步骤S2，数据服务器300根据匹配关系确定需要加载至车辆的刷写文件以及对应的刷写验证程序(即诊断程序)。

本实施例中，由于数据服务器300中各个诊断程序与诊断站点预先存储有对应关系，因此可以匹配出关联的诊断程序。在实际应用中，还可以进一步根据车辆的基础信息来完成诊断程序的匹配。

另外，在确定出刷写文件后，数据服务器还需要根据车辆的基础信息对刷写文件进行准确性验证，如版本号校验等，从而避免刷写文件出错。

步骤S3，数据服务器300通过运行服务控制诊断装置100与车辆完成通信连接，进一步基于刷写文件以及刷写验证程序与诊断装置100共同完成诊断操作。

具体地，数据服务器300会将刷写文件封装并通过远程调用服务发送给诊断装置100的进程通信管理服务，接下来诊断装置100就会通过中间层2003、协议层2002以及操作系统层2001逐层对刷写文件进行处理(如解包、根据车辆支持的通讯协议封装、调用接口组件20传输等)并将该刷写文件刷写至车辆中。

接下来，在刷写完成后，数据服务器300执行刷写验证程序，该刷写验证程序诊断装置100发送相关请求，进程通信管理服务通过RPC服务使得进程调用管理服务接收上述相关请求；进程调用管理服务根据相关请求从应用层2004中确定需要调用的预设服务，并通过该预设服务调用协议层2003中的相关协议。

若相关请求为硬件调用请求，则被确定的硬件相关的预设服务会对相关硬件协议进行调用，硬件协议进一步调用操作系统层2001的驱动使得相关诊断系统硬件1001执行对应操作。

若相关请求为通讯请求，则进程调用管理服务会控制车辆通讯服务获取该通讯请求，解析来车辆通讯服务调用之前确定的通讯协议对通讯请求进行封装，发送给操作系统层2001，操作系统层2001调用接口模块20，将封装后的通讯请求通过接口模块20发送给车辆。

最终，刷写验证程序完成对车辆中写入文件的完整性验证(即刷写的数据与车辆模块真正写入的数据一致)，生成验证结果。

以上为对车辆进行软件刷写操作的系统流程，同理，其他车辆的诊断流程与该流程类似。

若诊断结束后，诊断结果表示为车辆存在故障，数据服务器300会根据匹配关系将诊断结果及故障排查通知发送给相应诊断人员的手持终端200上，提醒该诊断人员对车辆执行故障排除操作。当诊断人员完成故障排除后，需要重新执行相应的故障排除程序，具体介绍如下：

手持终端200通过显示器73让诊断人员选择、调整和/或执行故障排除程序，数据服务器300在诊断人员确认执行故障排除操作时，基于终端识别信息与装置识别信息的关联关系确定对应的诊断装置100，并通过运行服务运行故障排除程序，从而通过诊断装置100完成对车辆的故障排除操作。数据服务器300运行故障排除程序的过程与诊断程序的运行过程类似，在此不再赘述。

<实施例二>

与实施例一的区别在于，本实施例二中，每当有一个新的车辆开始下线诊断操作，诊断人员就会将一个诊断装置100(可以是任意一个)与车辆进行连接，并在之后的所有诊断测试中，该诊断装置100不需要断开连接，可以一直在不同诊断站点执行不同诊断操作，直至车辆完成所有诊断后才断开连接。也就是说，本实施例二中，在一次完整的车辆诊断过程中，诊断装置100与车辆一一对应。在诊断装置100与车辆进行连接后，诊断装置100就通过通讯协议与车辆进行通信连接，并获取该车辆的基础信息，与诊断装置100的装置识别信息一并发送给数据服务器300进行验证匹配。

本实施例二中，每个诊断站点设有对应的识别装置，每当车辆进入诊断站点，该识别装置就会自动识别出车辆的车辆识别信息(例如可以识别车辆的VIN码)，并将该车辆识别信息与诊断站点的站点信息发送给数据服务器300进行验证匹配得到匹配关系。

通过上述过程，车辆诊断系统即可自动建立诊断装置100、车辆以及诊断站点之间的匹配关系，并在后续有数据服务器300自动匹配诊断程序对车辆执行诊断操作。

另外，本实施例二中，每当数据服务器300基于诊断程序与诊断装置共同完成一次诊断操作且诊断成功时，数据服务器300还会根据匹配关系以及预设的车辆诊断流程预测车辆下一次需要执行的诊断操作并确定相应的诊断程序，进一步将该诊断程序发送给诊断装置100对替换已完成诊断的诊断程序。通过这样的方式，可以在诊断装置100中提前加载诊断程序，提高整个车辆诊断过程的生产节拍，并在一定程度上避免因信号不良导致诊断程序没有及时加载至终端影响车辆诊断效率的问题。

最后应说明的是：以上所述实施例，仅为本发明的具体实施方式，用以说明本发明的技术方案，而非对其限制，本发明的保护范围并不局限于此，尽管参照前述实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，其依然可以对前述实施例所记载的技术方案进行修改或可轻易想到变化，或者对其中部分技术特征进行等同替换；而这些修改、变化或者替换，并不使相应技术方案的本质脱离本发明实施例技术方案的精神和范围，都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应所述以权利要求的保护范围为准。

Claims (10)

1.一种车辆诊断系统，用于对车辆进行诊断，其特征在于，包括：

数据服务器；以及

多个诊断装置，与所述数据服务器相通信连接，

其中，当所述诊断装置通过对外接口与所述车辆连接时，所述数据服务器对所述车辆的基础信息、所述诊断装置的装置识别信息、所述车辆所处的诊断站点的站点信息进行验证匹配形成匹配关系，

所述数据服务器根据所述匹配关系确定所述车辆在所述诊断站点需要执行的诊断操作所对应的诊断程序，

所述诊断装置与所述车辆通信连接，并用于完成预定程度的诊断操作，

所述数据服务器与所述诊断装置基于所述诊断程序共同完成全部的所述诊断操作。

2.根据权利要求1所述的车辆诊断系统，其特征在于：

其中，任意一个诊断终端能够被相应所述诊断站点获取该诊断终端的装置识别信息，并与站点信息一并发送给所述数据服务器进行所述验证匹配，

每当所述车辆需要执行新的诊断操作，所述诊断装置与所述车辆进行连接时，所述诊断装置通过设置在该诊断装置中的通讯协议与所述车辆进行通信连接，并获取该车辆的基础信息发送给所述数据服务器进行所述验证匹配得到所述匹配关系。

3.根据权利要求1所述的车辆诊断系统，其特征在于：

其中，所述诊断装置与所述车辆一一对应，

所述诊断装置通过对外接口与所述车辆连接发生在所述车辆执行第一次所述诊断操作前，

在所述诊断装置与所述车辆进行连接后，所述诊断装置通过设置在该诊断装置中的通讯协议与所述车辆进行通信连接，并获取该车辆的基础信息发送给所述数据服务器进行所述验证匹配，

每个所述诊断站点设有对应的识别装置，每当所述车辆进入所述诊断站点，所述识别装置识别出所述车辆的车辆识别信息，并将该车辆识别信息与所述诊断站点的站点信息发送给所述数据服务器进行所述验证匹配得到所述匹配关系。

4.根据权利要求1所述的车辆诊断系统，其特征在于，

所述诊断装置中预先存储有协议栈以及用于对所述协议栈进行调用的预设服务，

所述数据服务器与所述诊断装置基于所述诊断程序共同完成全部的所述诊断操作，包括：

所述数据服务器将所述诊断程序发送并存储至所述诊断装置，并控制所述诊断装置执行所述诊断程序，

所述诊断装置在执行过程中通过所述预设服务调用所述协议栈完成与所述车辆的数据交互，得到所述车辆反馈的诊断结果，

所述诊断结果暂存在所述诊断装置中并在所述诊断装置与所述数据服务器相通信连接时发送给该数据服务器。

5.根据权利要求1所述的车辆诊断系统，其特征在于，

所述诊断装置中预先存储有协议栈以及用于对所述协议栈进行调用的预设服务，

所述基于所述诊断程序与所述诊断装置共同完成所述诊断操作，包括：

所述数据服务器执行所述诊断程序，

所述诊断装置在执行过程中通过所述预设服务调用所述协议栈完成所述数据服务器、所述诊断装置与所述车辆的数据交互，使得所述数据服务器得到所述车辆反馈的诊断结果并进行存储。

6.根据权利要求1所述的车辆诊断系统，其特征在于：

其中，所述诊断操作为程序刷写操作，

所述数据服务器根据所述匹配关系确定所述车辆在所述诊断站点需要执行的诊断操作所对应的诊断程序时，还根据所述站点信息确认需要加载至所述车辆的刷写文件，并根据所述基础信息对所述刷写文件进行准确性验证，

所述数据服务器在基于所述诊断程序与所述诊断装置共同完成所述诊断操作之前，通过所述诊断装置将所述刷写文件刷写至所述车辆中。

7.根据权利要求1所述的车辆诊断系统，其特征在于，还包括：

至少一个手持终端，由所述诊断人员持有，与所述数据服务器相通信连接，

其中，所述手持终端具有扫码器，并存储有所述诊断人员所处诊断站点的站点信息，

所述诊断装置上设有包含所述装置识别信息的装置标识，

当所述诊断人员通过所述扫码器对所述装置标识进行扫描，所述手持终端就获取到相应的所述装置识别信息，并将该装置识别信息与存储的所述站点信息对应发送给所述数据服务器进行所述验证匹配，

当所述数据服务器与所述诊断装置共同完成所述诊断操作后，所述数据服务器将相应的诊断结果根据所述匹配关系发送给所述手持终端给所述诊断人员确认。

8.根据权利要求7所述的车辆诊断系统，其特征在于：

其中，所述手持终端具有交互界面，用于让所述诊断人员选择、调整和/或执行一个或多个诊断程序，

当所述诊断操作的诊断结果表示为诊断失败时，所述数据服务器根据所述站点信息将诊断失败消息及诊断结果发送给对应的所述手持终端，使得所述诊断人员执行故障排除操作并在排除后通过所述手持终端选择待执行的诊断程序，

所述数据服务器在所述诊断人员确认执行故障排除操作时，基于所述终端识别信息与所述装置识别信息的关联关系确定对应的所述诊断装置，并运行故障排除程序，从而通过所述诊断装置完成对所述车辆的故障排除操作。

9.根据权利要求3所述的车辆诊断系统，其特征在于：

其中，每当所述数据服务器基于所述诊断程序与所述诊断装置共同完成一次所述诊断操作且诊断成功时，所述数据服务器就根据所述匹配关系以及预设的车辆诊断流程预测所述车辆下一次需要执行的诊断操作并确定相应的诊断程序，进一步将该诊断程序发送给所述诊断装置对替换已完成诊断的所述诊断程序。

10.根据权利要求1所述的车辆诊断系统，其特征在于，所述诊断装置包括：

核心板，所述核心板上设有诊断模块、缓存模块以及无线模组；

接口组件，与所述车辆的对外接口相适配；

交互组件，用于使得所述诊断模块与诊断人员进行人机交互；

电源组件，与所述接口组件、所述无线模组以及所述诊断模块电连接，用于提供电源及进行电源适配；以及

扩展接口组件，与所述诊断模块电连接，

其中，所述诊断模块通过所述接口组件与所述车辆电连接并用于对所述车辆执行诊断，

所述缓存模块与所述诊断模块电连接，用于对所述诊断模块执行所述诊断产生的数据进行缓存，

所述无线模组与所述诊断模块电连接，用于将所述诊断模块与所述数据服务器进行连接，

所述扩展接口组件为USB接口、Type-C接口、闪存接口、Pogo Pin接口中的任意一种或多种。