CN117032192A - 一种用于车辆诊断的核心系统、装置及方法 - Google Patents

Abstract

本发明公开了一种用于车辆诊断的核心系统、装置及方法，用于车辆诊断的核心系统，与车辆相通信连接，包括：操作系统层，包括操作系统及与诊断系统硬件相对应的驱动；协议层，包括与诊断系统硬件相对应的硬件协议栈，硬件协议栈设置有多类硬件协议；服务层，设有多个与硬件协议的类型相对应的预设服务；以及应用层，包括诊断程序，该诊断程序用于对车辆执行诊断操作，其中，当诊断程序执行诊断操作产生硬件调用请求时，将该硬件调用请求发送给相应类型的预设服务，各个预设服务根据当前接收到的所有硬件调用请求确定硬件调度策略，并根据该硬件调度策略对相应类型的硬件协议进行调度，从而使得诊断程序在诊断操作过程中完成对诊断系统硬件的控制。

Description

一种用于车辆诊断的核心系统、装置及方法

技术领域

本发明涉及汽车诊断技术领域，尤其涉及一种用于车辆诊断的核心系统、装置及方法。

背景技术

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

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

但这样仍然存在一些问题，由于诊断功能分散到不同的模块中，会导致系统的集成和协调成为一项挑战，即不同模块之间的通讯和协同工作需要进行复杂的设计和调试，增加了系统的复杂性和开发成本。同时，由于现有技术中的诊断功能通常是针对特定车型或特定诊断需求设计的，因此在开发不同的诊断功能，往往会在一些基础的协议、服务上重复开发，提高了开发成本。

发明内容

本发明的目的就在于提供用于车辆诊断的核心系统及装置，可以有效提高诊断设备对不同诊断程序的兼容性，降低开发成本和适配成本。

本发明提供的一种用于车辆诊断的核心系统，与车辆以及数据服务器分别相通信连接，其特征在于，包括：操作系统层，包括操作系统及与诊断系统硬件相对应的驱动；协议层，包括与诊断系统硬件相对应的硬件协议栈，硬件协议栈设置有多类硬件协议；以及服务层，设有多个与硬件协议的类型相对应的预设服务，其中，当接收到诊断程序被运行从而执行车辆诊断操作时产生的硬件调用请求时，各个预设服务根据当前接收到的所有硬件调用请求确定硬件调度策略，并根据该硬件调度策略对相应类型的硬件协议进行调度，从而使得诊断程序在诊断操作过程中完成对诊断系统硬件的控制，服务层对车辆被执行诊断操作时反馈的诊断结果进行数据整合及暂存，并在与数据服务器建立通信连接时发送给该数据服务器。

进一步地，本发明提供的用于车辆诊断的核心系统，还可以具有这样的技术特征，其中，服务层还设有远程调用服务，诊断程序与服务层设置于不同且相互通信连接的处理器，由该不同的处理器共同执行诊断程序完成车辆诊断操作，当诊断程序产生硬件调用请求时，将硬件调用请求发送给远程调用服务，由远程调用服务基于该硬件调用请求对相应的预设服务完成调用，从而使不同且相互通信连接的处理器能够共同完成车辆的诊断操作。

进一步地，本发明提供的用于车辆诊断的核心系统，还可以具有这样的技术特征，还包括：应用层，包括诊断程序，其中，服务层、协议层以及操作系统层设置在第一处理器上，应用层设置在数据服务器，不同且相互通信连接的处理器为第一处理器和数据服务器，诊断操作为在车辆行驶过程中执行的标定操作，当启动标定操作时，数据服务器运行诊断程序，产生的请求封装后通过远程调用服务发送给第一处理器，服务层中相应的预设服务会响应封装后的请求进行初始化，并调用协议层、协议层、操作系统层、诊断系统硬件逐层完成初始化并进入标定模式。

进一步地，本发明提供的用于车辆诊断的核心系统，还可以具有这样的技术特征，其中，在进入标定模式后，针对诊断程序产生的请求，预设服务在接收到封装后的请求时，调用协议层对请求进行二次封装，协议层进一步通过操作系统层对硬件接口进行调用从而将二次封装后的请求发送给车辆；针对车辆反馈的诊断数据，操作系统层获取并对诊断数据进行整理和暂存，预设服务调用协议层对诊断数据进行拆包和/或封包，进一步通过远程调用服务发送至第二装置，使得诊断程序进行业务逻辑处理判断。

进一步地，本发明提供的用于车辆诊断的核心系统，还可以具有这样的技术特征，还包括：应用层，包括至少一个诊断程序，操作系统层、协议栈、服务层以及应用层设置于同一处理器上，诊断操作为在车辆行驶过程中执行的标定操作，当启动标定操作时，处理器运行诊断程序，产生的请求发送给服务层，服务层中相应的预设服务会响应封装后的请求进行初始化，并调用协议层、协议层、操作系统层、诊断系统硬件逐层完成初始化并进入标定模式。

进一步地，本发明提供的用于车辆诊断的核心系统，还可以具有这样的技术特征，其中，处理器连接有接口电路，接口电路包括连接器接口、至少两路适配用接口以及自动切换开关，连接器接口与对外接口的型号相适配，自动切换开关设置在连接器接口与适配用接口之间，用于根据对外接口输出的信号类型切换匹配对应的适配用接口，协议层还包括网络协议栈以及CAN协议栈，服务层还包括用于对网络协议栈以及CAN协议栈进行调度的车辆通讯服务，当自动切换开关切换匹配对应的适配用接口之后，车辆通讯服务还根据对外接口输出的信号类型从网络协议栈和/或CAN协议栈确定出对应的通讯协议作为当前通讯协议，并在执行车辆诊断操作时基于该当前通讯协议完成通信交互。

进一步地，本发明提供的用于车辆诊断的核心系统，还可以具有这样的技术特征，其中，协议层还包括网络协议栈以及CAN协议栈，服务层还包括用于对网络协议栈以及CAN协议栈进行调度的车辆通讯服务，当车辆进行通讯连接时，车辆通讯服务对网络协议栈和/或CAN协议栈进行调度从而完成通讯连接，当诊断程序执行车辆诊断操作时，相应的车辆诊断数据通过车辆通讯请求发送给车辆通讯服务，该车辆通讯服务根据当前接收到的所有车辆通讯请求确定通讯调度策略，并根据该通讯调度策略调用网络协议栈和/或CAN协议栈完成车辆诊断数据以及诊断结果的传输。

进一步地，本发明提供的用于车辆诊断的核心系统，还可以具有这样的技术特征，其中，硬件调度策略包括：确定本预设服务所对应的各硬件协议是否被两个以上的当前接收到的硬件调用请求所调用，若是，则根据硬件调用请求的时间戳和/或优先级对硬件调用请求进行排序，从而优先处理排序最前的硬件调用请求，并依序处理后续的硬件调用请求，当硬件调用请求被确定为等待后续处理时，预设服务发出等待报文给相应的诊断程序。

本发明还提供了一种用于车辆诊断的核心装置，具有这样的技术特征，装置上设置有上述任意一项的用于车辆诊断的核心系统。

本发明还提供了一种车辆下线中需在车辆行驶状态下进行诊断的方法，具有这样的技术特征，通过核心装置对处于行驶状态下的车辆进行诊断，该核心装置上设置有上述任意一项的用于车辆诊断的核心系统。

发明作用与效果

根据本发明提供的用于车辆诊断的核心系统、装置及方法，由于通过在核心装置上设置基础的操作系统层、协议层以及服务层，在响应诊断程序时通过服务层的预设服务确定硬件调度策略对协议层、操作系统层进行逐层调用，完成对装置硬件和车辆的调用，因此本发明的核心系统可以使得诊断装置的处理器可以仅专注于基础服务、协议、系统的运行和调用，大大减少了处理器的计算资源负担，使得诊断装置可以通过更低的成本来挑选性能不高的处理器完成诊断，并具备对不同的诊断程序的兼容性。同时，诊断程序可以灵活地设置在与核心装置相连接的服务器、其他高性能处理器、或者核心装置的处理器本身(在该处理器的性能足以支持时)，从而在车辆下线诊断过程中可以动态调整诊断程序的部署。

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

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

附图说明

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

图1为本发明实施例提供的车辆诊断系统的示意图。

图2是本发明实施例中用于车辆诊断的核心系统的结构框图。

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

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

图5是本发明实施例中对车辆执行雷达标定检测的时序图。

具体实施方式

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

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

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

<实施例>

本实施例用于车辆的核心系统基于一种车辆诊断装置实现。本实施例中，车辆诊断装置能够通过接口组件与车辆的对外接口进行有线连接，该车辆诊断装置与服务器通过本实施例的核心系统共同完成对车辆的诊断操作。

图1为本发明实施例提供的车辆诊断系统的示意图，图2是本发明实施例中用于车辆诊断的核心系统的结构框图。参考图1，车辆诊断系统1000包括多个车辆诊断装置100以及与其相通信连接的主控制器200，在车辆诊断系统1000上设有核心系统2000，该系统2000具体包括操作系统层2001、协议层2002、服务层2003以及应用层2004。

首先对车辆诊断系统1000做具体阐述。

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

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

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

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

基板用于固定以及使得诊断模块130、缓存模块131、无线模组150、接口组件20、交互组件30、电源组件40以及扩展接口组件50等硬件完成电连接，在本实施例中，基板是一块电路板。

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

然而，由于实际车辆诊断程序较多，因此低成本的诊断模块130可能无法存储所有的诊断程序，此时，若车辆诊断装置100需要执行并未加载的诊断程序，诊断模块130可以与主控制器200相连接，从主控制器200中获取诊断程序并完成加载或替换。或者，诊断模块130也可以不加载诊断程序，通过主控制器200来运行诊断程序，并通过车辆诊断装置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部分安装与壳体上、部分安装与基板上，用于连接车辆的对外接口。该接口组件20包括连接器接口121、两路适配用接口122(1)、122(2)以及自动切换开关123。

其中，连接器接口121与车辆的对外接口的型号相匹配，例如是OBD接口或其他工业级连接器接口，该连接器接口121安装在壳体上，从而便于诊断人员将车辆诊断装置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与用户进行人机交互。

作为一种具体实施方式，如图3所示，交互组件30包括触摸屏193、五个提示灯191以及五个按键192。具体地，壳体正面(即车辆诊断装置100在使用时面向用户的一面)可以开设有屏幕安装槽，并在屏幕安装槽的下方开设有与提示灯191以及按键192的数量和形状相适配的十个安装孔。

触摸屏193用于提供显示及输入，安装在屏幕安装槽内，并通过数据连接线与诊断模块130电连接。本实施例中，触摸屏193可以是触控LCD屏幕，用于根据诊断模块130中所存储的诊断程序显示相应界面并使得诊断人员可以执行相关操作。

需要说明的是，尽管本实施例中触摸屏193为触控屏幕，诊断人员可以通过触控屏幕输入操作指令，但在实际应用中，触摸屏193也可以替换为普通屏幕，使得诊断人员通过按键192进行操作。

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

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

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

需要说明的是，尽管本实施例中描述的提示灯191以及按键192均设置在触摸屏193的下方，但在实际应用中，提示灯191以及按键192也可以设置在触摸屏侧面、或者壳体的侧边等其他便于用户观察和使用的位置，本实施例对此不作限制。并且，可以理解的是，提示灯191以及按键192的数量以及对应的功能也可以根据实际开发需要进行调整，本实施例中对此亦不作限制。

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

电源组件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也可以仅包含实现本申请实施例方案所必需的组件，而不必包含图中所示的全部组件。

主控制器200用于和车辆诊断装置100共同完成对车辆的诊断。本实施例中，主控制器200为一个数据服务器200，还用于对各个车辆诊断装置100进行管理，以及对车辆诊断装置100上传的诊断数据和诊断结构进行存储和处理。

作为一种实施形态，数据服务器200中设有复数个运行服务，并存储有所有的诊断程序。运行服务用于执行诊断程序。

在其他实施方案中，主控制器200也可以是与车辆诊断装置100相通信连接的其他终端、计算机等计算设备，本实施例对此不作限制。

以上为车辆诊断系统1000的具体介绍，接下来针对核心系统2000做具体阐述。

参考图2，核心系统2000具体包括操作系统层2001、协议层2002、服务层2003以及应用层2004。

操作系统层2001包括操作系统以及与诊断系统硬件1001相对应的驱动(诊断系统硬件1001即车辆诊断装置100中的无线模组150、蓝牙模块170、接口组件20、交互组件30、电源组件40以及扩展接口组件50等硬件)。

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

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

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

服务层2003包括多个预设服务，该预设服务用于对硬件协议栈以及网络协议栈进行调度管理。不同的预设服务分别对应有各自协议的类型，当预设服务接收到应用层2004输出的调用请求时，就会依据对应的类型去调用相应的协议。

若调用请求为硬件调用请求，则相关预设服务会从硬件协议栈中相应地调用硬件协议，并使得硬件协议通过操作系统层2001的驱动来控制控制诊断系统硬件1001执行相关操作，从而实现诊断程序所需要实现的功能。

若调用请求为通讯请求，则相关预设服务会从网络协议栈中相应地调用通讯协议，并使得通讯协议对数据进行解包、封包、传输等操作。

本实施例中，预设服务包括用于对网络协议栈以及CAN协议栈进行调用的车辆通讯服务以及各种与硬件协议的类型相对应的硬件调用服务。

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

当车辆诊断装置100与车辆进行连接时，自动切换开关123会切换匹配对应的适配用接口122，之后，车辆通讯服务还根据对外接口输出的信号类型网络协议栈和/或CAN协议栈确定出与当前车辆相适配的通讯协议，并在后续与车辆的通讯过程中均采用该适配的通讯协议完成数据交换。

另外，当预设服务接收到多个硬件调用请求时，会据当前接收到的所有硬件调用请求确定硬件调度策略，并根据该硬件调度策略对相应类型的硬件协议进行调度，从而使得诊断程序在诊断操作过程中完成对诊断系统硬件的控制。

具体地，硬件调度策略包括以下步骤：

确定本预设服务所对应的各硬件协议是否被两个以上的当前接收到的硬件调用请求所调用；

若是，则根据硬件调用请求的时间戳和/或优先级对硬件调用请求进行排序，从而优先处理排序最前的硬件调用请求，并依序处理后续的硬件调用请求；

当硬件调用请求被确定为等待后续处理时，预设服务发出等待报文给相应的诊断程序。

通过上述硬件调度策略，可以避免应用层2004对硬件的调用发生冲突。

本实施例中，操作系统层2001、协议层2002、服务层2003设置在诊断装置100上；应用层2004部分地设置于诊断装置100并全部地设置于数据服务器200上，即，诊断装置100上设有部分诊断程序，而服务器上设有全部的诊断程序。

服务层2003还设有远程调用服务，可以是RPC服务。当数据服务器200或其他计算设备执行诊断程序时，能够将产生的调用请求通过远程调用服务发送给车辆诊断装置100的服务层2003，随后相应的预设服务响应调用请求并调用相应的协议完成数据服务器200、诊断装置100与车辆之间的数据交互。后续在通信过程中由车辆反馈的诊断数据及诊断结果也可以通过远程调用服务发送给数据服务器200进行存储。这样就实现了数据服务器200与车辆诊断装置100共同完成对车辆的诊断操作。

作为另一种实施形态，当诊断装置100执行诊断程序时，相关的调用请求会直接发送给对应的预设服务，并通过该预设服务调用相应的协议完成车辆诊断装置100与车辆的数据交互。服务层2003会对后续通信过程中车辆反馈的诊断数据及诊断结果进行数据整合并暂存，直到车辆诊断装置100与数据服务器200建立通信连接时将诊断数据及诊断结果发送给数据服务器200进行存储。这样也可以实现数据服务器200与诊断装置100共同完成对车辆的诊断操作。

其中，服务层2003对诊断数据及诊断结果进行数据整合的操作也是通过预设服务来执行的，如通讯协议服务，该通讯协议服务能够将诊断数据及诊断结果整理为待发送的数据包，并将其暂存在缓存模块131，直到与数据服务器200建立通信连接将其上传。

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

在实际应用中，数据服务器200可以对诊断装置100上设有的部分诊断程序进行覆写调整操作。例如，诊断装置100中原本设有雷达标定、车窗标定软件，但当诊断人员完成这些诊断操作，并需要执行软件刷写操作时，可以通过诊断装置100的交互组件30选定安装软件刷写程序，此时数据服务器200就会将存储的软件刷写程序通过无线通信安装至诊断装置100上。

上述的车辆诊断系统1000及其设置的核心系统2000可以应用于车辆下线检测过程中的所有诊断项目。特别地，针对一些需要车辆在行驶状态下才能诊断的程序，如雷达标定测试，本方案也可以有效支持，使得诊断人员便捷地完成标定操作，以下结合时序图对这种测试状态做具体介绍。

图5是本发明实施例中对车辆执行雷达标定检测的时序图。

如图5所示，针对整车下线检测中，在车辆驾驶过程中进行雷达标定测试为例，车辆诊断系统1000及核心系统2000在诊断操作过程中的数据处理流程详细如下：

在开始雷达标定检测前，车辆诊断装置100已经与车辆完成连接并根据该车辆的车型确定了相应的通讯协议。

首先，进入车辆诊断装置100的标定准备流程，诊断人员需要将车辆驶入跑到并启动诊断程序(以下简称APP)。APP被启动后车辆诊断系统1000与核心系统2000的具体流程如下：

数据服务器200运行诊断程序，该诊断程序通过RPC服务向车辆诊断装置100发送启动APP请求；

车辆诊断装置100中服务层2003的相关预设服务响应启动APP请求，并进行初始化；

预设服务初始化时将其在协议层2002对应的协议进行初始化，协议初始化时将其在操作系统层2001对应的资源进行初始化，操作系统2001资源在初始化时确认相应的诊断系统硬件的硬件接口可用；

从硬件层面、操作系统层2001、协议层2002、服务层2003、应用层2004逐层向上层返回启动结果，诊断程序在接收到启动结果后等待进入雷达标定流程。

需要说明的是，本实施例中的诊断程序在数据服务器200中运行，因此需要通过RPC服务来接收APP请求。在其他实施形态中，若诊断程序在车辆诊断装置100上运行，则可以不需要RPC服务，诊断程序产生的请求会直接发送给预设服务。

接下来，诊断人员在确定车辆及准备工作到位后，点击车辆诊断装置100使得诊断程序进入标定模式。在标定模式中，车辆诊断装置100会与车辆保持通讯连接，并实时将诊断程序产生的请求以及车辆返回的诊断数据进行数据交换，诊断程序请求发送的具体流程如下：

数据服务器200中的诊断程序产生通讯请求，通过RPC服务发送给车辆诊断装置100，服务层2003的车辆通讯服务获取该通讯请求；

车辆通讯服务调用之前与车辆连接时确定的通讯协议对通讯请求进行封装，发送给操作系统层2001；

操作系统层2001调用接口模块20，将封装后的通讯请求通过接口模块20发送给车辆。

在标定模式中，操作系统层2001会通过接口模块20对车辆的状态进行持续监控。一旦获取到车辆反馈的诊断数据(如雷达检测数据)，相应诊断数据反馈的具体流程如下：

操作系统层2001通过接口模块20获取到车辆反馈的诊断数据，对该诊断数据进行整理并暂存；

车辆通讯服务调用之前与车辆连接时确定的通讯协议对诊断数据进行拆包/封包；

远程调用服务将拆包/封包后的诊断数据给发送给数据服务器200，使得诊断程序进行后续的业务逻辑处理判断，同时，通讯协议服务会对本次雷达标定过程中所有的诊断数据进行整合。

标定模式下会不断重复上述过程直至标定结束。

最后，通讯协议服务会将雷达标定过程中所有的诊断数据以及诊断程序产生的数据整合形成诊断结果，该诊断结果会暂存至操作系统层2001(缓存模块131)中。一旦车辆诊断装置100与数据服务器200建立通信连接，就会将诊断结果发送给数据服务器200，具体流程如下：

应用层2004的某一诊断程序(例如结果上传程序)检测到车辆诊断装置100与数据服务器200建立通讯连接，向通讯协议服务发起上传请求；

通讯协议服务确定所有需要上传的诊断结果，并控制相应的预设服务启动相应的数据接口通讯协议；

数据接口通讯协议从操作系统层2001(缓存模块131)中获取相关的诊断结果，并在验证数据完整性后发送给协议层2002；

数据接口通讯协议对诊断结果拆包/封包，通讯协议服务将拆包/封包后的诊断结果通过远程调用服务上传给数据服务器200。

在上述过程中，操作系统层2001(缓存模块131)中暂存的诊断结果可以是多次诊断的结果，在车辆诊断装置100连接上数据服务器200，通讯协议服务会一次性上传所有的诊断结果。在实际应用中，若两者的连接时长无法上传完所有的诊断结果，通讯协议服务也可以记录上一次诊断结果上传的节点，在下一次从记录的节点开始上传，从而实现断点续传的功能。

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

Claims (10)

1.一种用于车辆诊断的核心系统，与车辆以及数据服务器分别相通信连接，其特征在于，包括：

操作系统层，包括操作系统及与诊断系统硬件相对应的驱动；

协议层，包括与所述诊断系统硬件相对应的硬件协议栈，所述硬件协议栈设置有多类硬件协议；以及

服务层，设有多个与所述硬件协议的类型相对应的预设服务，

其中，当接收到诊断程序被运行从而执行车辆诊断操作时产生的硬件调用请求时，各个所述预设服务根据当前接收到的所有所述硬件调用请求确定硬件调度策略，并根据该硬件调度策略对相应类型的所述硬件协议进行调度，从而使得所述诊断程序在所述诊断操作过程中完成对所述诊断系统硬件的控制，

所述服务层对所述车辆被执行所述诊断操作时反馈的诊断结果进行数据整合及暂存，并在与所述数据服务器建立通信连接时发送给该数据服务器。

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

其中，所述服务层还设有远程调用服务，

所述诊断程序与所述服务层设置于不同且相互通信连接的处理器，由该不同的处理器共同执行所述诊断程序完成所述车辆诊断操作，

当所述诊断程序产生所述硬件调用请求时，将所述硬件调用请求发送给所述远程调用服务，由所述远程调用服务基于该硬件调用请求对相应的所述预设服务完成调用，从而使所述不同且相互通信连接的处理器能够共同完成所述车辆的诊断操作。

3.根据权利要求2所述的用于车辆诊断的核心系统，其特征在于，还包括：

应用层，包括所述诊断程序，

其中，所述服务层、所述协议层以及所述操作系统层设置在第一处理器上，所述应用层设置在所述数据服务器，所述不同且相互通信连接的处理器为所述第一处理器和所述数据服务器，

所述诊断操作为在车辆行驶过程中执行的标定操作，

当启动所述标定操作时，所述数据服务器运行所述诊断程序，产生的请求封装后通过所述远程调用服务发送给所述第一处理器，

所述服务层中相应的预设服务会响应封装后的所述请求进行初始化，并调用协议层、协议层、操作系统层、诊断系统硬件逐层完成初始化并进入标定模式。

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

其中，在进入标定模式后，

针对所述诊断程序产生的请求，所述预设服务在接收到封装后的所述请求时，调用所述协议层对所述请求进行二次封装，所述协议层进一步通过所述操作系统层对硬件接口进行调用从而将二次封装后的所述请求发送给所述车辆；

针对所述车辆反馈的诊断数据，所述操作系统层获取并对所述诊断数据进行整理和暂存，所述预设服务调用所述协议层对所述诊断数据进行拆包和/或封包，进一步通过所述远程调用服务发送至所述第二装置，使得所述诊断程序进行业务逻辑处理判断。

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

应用层，包括至少一个所述诊断程序，

所述操作系统层、所述协议栈、所述服务层以及所述应用层设置于同一处理器上，

所述诊断操作为在车辆行驶过程中执行的标定操作，

当启动所述标定操作时，所述处理器运行所述诊断程序，产生的请求发送给所述服务层，所述服务层中相应的预设服务会响应封装后的所述请求进行初始化，并调用协议层、协议层、操作系统层、诊断系统硬件逐层完成初始化并进入标定模式。

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

其中，所述处理器连接有接口电路，

所述接口电路包括连接器接口、至少两路适配用接口以及自动切换开关，

所述连接器接口与所述对外接口的型号相适配，

所述自动切换开关设置在所述连接器接口与所述适配用接口之间，用于根据所述对外接口输出的信号类型切换匹配对应的所述适配用接口，

所述协议层还包括网络协议栈以及CAN协议栈，

所述服务层还包括用于对所述网络协议栈以及所述CAN协议栈进行调度的车辆通讯服务，

当所述自动切换开关切换匹配对应的所述适配用接口之后，所述车辆通讯服务还根据所述对外接口输出的信号类型从所述网络协议栈和/或所述CAN协议栈确定出对应的通讯协议作为当前通讯协议，并在执行所述车辆诊断操作时基于该当前通讯协议完成通信交互。

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

其中，所述协议层还包括网络协议栈以及CAN协议栈，

所述服务层还包括用于对所述网络协议栈以及所述CAN协议栈进行调度的车辆通讯服务，

当所述车辆进行通讯连接时，所述车辆通讯服务对所述网络协议栈和/或所述CAN协议栈进行调度从而完成所述通讯连接，

当所述诊断程序执行所述车辆诊断操作时，相应的车辆诊断数据通过车辆通讯请求发送给所述车辆通讯服务，该车辆通讯服务根据当前接收到的所有所述车辆通讯请求确定通讯调度策略，并根据该通讯调度策略调用所述网络协议栈和/或所述CAN协议栈完成所述车辆诊断数据以及所述诊断结果的传输。

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

其中，所述硬件调度策略包括：

确定本预设服务所对应的各所述硬件协议是否被两个以上的当前接收到的所述硬件调用请求所调用，

若是，则根据所述硬件调用请求的时间戳和/或优先级对所述硬件调用请求进行排序，从而优先处理排序最前的所述硬件调用请求，并依序处理后续的所述硬件调用请求，

当所述硬件调用请求被确定为等待后续处理时，所述预设服务发出等待报文给相应的所述诊断程序。

9.一种用于车辆诊断的核心装置，其特征在于，装置上设置有如权利要求1至8中任意一项所述的用于车辆诊断的核心系统。

10.一种车辆下线中需在车辆行驶状态下进行诊断的方法，其特征在于；

通过核心装置对处于行驶状态下的车辆进行诊断，该核心装置上设置有如权利要求1至8中任意一项所述的用于车辆诊断的核心系统。