CN117631639A - 一种跨平台车辆诊断系统 - Google Patents

Abstract

本发明公开了一种跨平台车辆诊断系统，能够在保证诊断性能的前提下，降低车辆诊断系统的开发成本，并提高其对不同诊断程序的兼容性，包括设置在与待诊断的车辆相连接的核心装置上的：操作系统层，包括操作系统及与诊断系统硬件相对应的驱动；协议层，包括硬件协议栈，硬件协议栈设置有多类与诊断系统硬件相对应的硬件驱动协议；以及中间层，设有进程调用管理服务以及进程通信管理服务，还包括：应用层，包括多个与硬件协议的类型相对应的预设服务以及至少一个诊断程序，该诊断程序用于对车辆执行诊断操作，其中，应用层至少部分地设置在核心装置上，应用层全部地设置在与核心装置相通信连接的第二装置上。

Description

一种跨平台车辆诊断系统

技术领域

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

背景技术

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

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

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

发明内容

本发明的目的就在于提供一种跨平台车辆诊断系统，在保证诊断性能的前提下，降低车辆诊断系统的开发成本，并提高其对不同诊断程序的兼容性。

本发明提供的一种跨平台车辆诊断系统，其特征在于；包括设置在与待诊断的车辆相连接的核心装置上的：操作系统层，包括操作系统及与诊断系统硬件相对应的驱动；协议层，包括硬件协议栈，硬件协议栈设置有多类与诊断系统硬件相对应的硬件驱动协议；以及中间层，设有进程调用管理服务以及进程通信管理服务，还包括：应用层，包括多个与硬件协议的类型相对应的预设服务以及至少一个诊断程序，该诊断程序用于对车辆执行诊断操作，其中，应用层至少部分地设置在核心装置上，应用层全部地设置在与核心装置相通信连接的第二装置上。进一步地，本发明提供的跨平台车辆诊断系统，还可以具有这样的技术特征，其中，每个预设服务独占一个进程，当诊断程序执行诊断操作产生硬件调用请求时，由进程调用管理服务根据硬件调用请求仲裁并分配相应类型的预设服务，并控制进程通信管理服务将硬件调用请求发送给预设服务对相应类型的硬件协议进行调用，从而使得诊断程序在诊断操作过程中完成对诊断系统硬件的控制，在诊断操作过程中，进程调用管理服务还用于对车辆反馈的诊断结果进行收集并在中间层进行数据整合。

进一步地，本发明提供的跨平台车辆诊断系统，还可以具有这样的技术特征，应用层至少部分地设置在核心装置上，诊断操作为在车辆行驶过程中执行的标定操作，当启动标定操作时，进程调用管理服务运行诊断程序，同时调用仲裁得到的预设服务进行初始化，使得协议层、操作系统层、诊断系统硬件逐层完成初始化并进入标定模式，在进入标定模式后，针对诊断程序产生的请求，进程调用管理服务控制预设服务调用协议层对请求进行封装，协议层进一步通过操作系统层对硬件接口进行调用从而将封装后的请求发送给车辆；针对车辆反馈的诊断数据，操作系统层获取并对诊断数据进行整理和暂存，进程调用管理服务控制预设服务调用协议层对诊断数据进行拆包和/或封包，进一步发送给诊断程序进行业务逻辑处理判断。

进一步地，本发明提供的跨平台车辆诊断系统，还可以具有这样的技术特征，应用层设置在与核心装置相通信连接的第二装置上，诊断操作为在车辆行驶过程中执行的标定操作，第二装置还设有用于对诊断程序的人机交互功能进行支持的第二操作系统层，当启动标定操作时，第二操作系统层运行诊断程序，产生的请求封装后通过进程通信管理服务发送给核心装置，进程调用管理服务接收封装后的请求，并通过进程通信管理服务调用仲裁得到的预设服务进行初始化，进程调用管理服务调用仲裁得到的预设服务进行初始化，使得协议层、操作系统层、诊断系统硬件逐层完成初始化并进入标定模式，在进入标定模式后，针对诊断程序产生的请求，进程调用管理服务在接收到封装后的请求时，控制预设服务调用协议层对请求进行二次封装，协议层进一步通过操作系统层对硬件接口进行调用从而将二次封装后的请求发送给车辆；针对车辆反馈的诊断数据，操作系统层获取并对诊断数据进行整理和暂存，进程调用管理服务控制预设服务调用协议层对诊断数据进行拆包和/或封包，进一步通过进程通信管理服务发送至第二装置，使得诊断程序进行业务逻辑处理判断。

进一步地，本发明提供的跨平台车辆诊断系统，还可以具有这样的技术特征，其中，进程通信管理服务支持有远程调用服务，当第二操作系统层运行诊断程序时，该诊断程序在运行时产生的硬件调用请求通过远程调用服务发送给进程通信管理服务。

进一步地，本发明提供的跨平台车辆诊断系统，还可以具有这样的技术特征，其中，当进程通信管理服务将硬件调用请求发送给预设服务对相应类型的硬件协议进行调用时，进程调用管理服务对预设服务输出的数据包进行完整性校验，若校验到数据包不完整，则请求相应的预设服务重新发送数据包并再次进行完整性校验直至校验到数据包完整。

进一步地，本发明提供的跨平台车辆诊断系统，还可以具有这样的技术特征，其中，当预设服务对硬件协议进行调用使其对诊断系统硬件进行控制时，进程调用管理服务对硬件协议中硬件的驱动标志位进行检测，从而判断硬件调用请求是否发生失效，当判断硬件调用请求发生错误时，根据预设逻辑对硬件协议的控制进行纠正，预设逻辑为控制硬件协议相硬件重新发起控制请求，并在预设时间内等待诊断系统硬件响应，若预设时间内没有响应，则判定发生失效，并向上层上报硬件调用错误。

进一步地，本发明提供的跨平台车辆诊断系统，还可以具有这样的技术特征，其中，在判定发生失效前，预设逻辑还包括：重启诊断系统硬件，并控制硬件协议重新发送硬件调用请求并等待预设时间；若重启后在预设时间内没有响应，判定发生失效。

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

进一步地，本发明提供的跨平台车辆诊断系统，还可以具有这样的技术特征，其中，当接收到进程通信管理服务发送的硬件调用请求时，各个预设服务根据当前接收到的所有硬件调用请求确定硬件调用策略，并根据该硬件调用策略对相应类型的硬件协议进行调用，从而使得诊断程序在诊断操作过程中完成对诊断系统硬件的控制。

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

发明作用与效果

根据本发明提供的跨平台车辆诊断系统，由于通过在核心装置上设置基础的操作系统层、协议层以及中间层，并独立出设有诊断程序和预设服务的应用层在第二装置或核心装置上，从而在响应诊断程序时通过中间层的进程调用管理服务根据所述硬件调用请求来分配预设服务，进一步对协议层、操作系统层进行逐层调用，完成对装置硬件和车辆的调用，同时，通过核心装置或操作装置来完成诊断程序的运行，因此本发明一方面保证了各类基础服务、协议、系统的兼容性，另一方面也保证了整个诊断系统能够以足够的性能来应对各类不同的诊断程序，保证了诊断系统的易用性。

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

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

附图说明

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

图1为本发明实施例提供的车辆诊断设备的结构示意图。

图2为本发明实施例提供的车辆诊断设备的结构框图。

图3是本发明实施例提供的跨平台车辆诊断系统的结构框图。

图4为本发明实施例提供的核心装置的结构框图。

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

具体实施方式

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

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

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

<实施例>

本实施例的跨平台车辆诊断系统基于一种具有核心装置以及操作装置的车辆诊断设备实现。本实施例中，车辆诊断设备能够通过对外接口与车辆进行有线连接，核心装置以及操作装置(即第二装置)通过跨平台车辆诊断系统共同完成对车辆的诊断操作。

图1为本发明实施例提供的车辆诊断设备的结构示意图，图2为本发明实施例提供的车辆诊断设备的结构框图，图3是本发明实施例提供的跨平台车辆诊断系统的结构框图。参考图1、图2及图3，车辆诊断设备1000包括核心装置100、操作装置200、扫码器300以及交互组件400。在该车辆诊断设备1000设有跨平台车辆诊断系统2000，该系统2000具体包括操作系统层2001、协议层2002、中间层2003以及应用层2004。

首先对车辆诊断设备1000的结构做具体阐述。

核心装置100具体包括第一壳体110、核心板10、接口模块20、散热模块30、电源模块40以及扩展接口模块50。

操作装置200至少具有第二壳体210、操作控制模块220以及显示器230。

如图1所示，显示器230设置在第二壳体210面向用户的一面，第一壳体110具有开口的一面，该开口的一面和第二壳体210上与显示器200相对的一面配合连接，从而实现核心装置100和操作装置200在结构上的固定连接。

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

特别地，应用层2004全部地设置在操作装置200上，并且部分地设置在核心装置100上。例如，应用层2004所包含的诊断程序以及预设服务在操作装置中均有加载，而核心装置100中仅加载必要的部分预设服务。在实际应用中，核心装置100中所加载的应用层2004可以根据实际需要进行调整，例如，还可以调整为将部分诊断程序加载至核心装置100中、或者调整为将全部的预设服务加载至核心装置100中等等。

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

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

核心板10用于实现核心装置100的主要诊断功能，如向车辆发送诊断信号、整理上传诊断数据等。如图4所示，核心板10包括基板，以及设置在基板上的诊断模块130、缓存模块131以及无线模组150。接下来，首先对核心板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主处理器连接。

本实施例中，在诊断过程中产生的诊断数据、处理结果、日志等数据会通过缓存模块131进行存储，同时，当车辆诊断设备1000通过无线模组150与数据服务器建立连接时，可以在诊断人员的操作下将缓存模块131中缓存的数据上传至数据服务器，由数据服务器对数据进行分析、统计、归档等处理。

在诊断过程中，具体地，因为ARM主处理器的兼容性，因此其上通过协议栈存储有多种在诊断过程中所需的通讯协议、硬件协议，诊断模块130可以基于这些协议与车辆完成通信并且完成对无线模组150等硬件的调用。同时，还由于ARM主处理器的并发性能，因此可以对操作装置200、车辆进行数据的并行收发，保证处理效率。

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

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

为实现车辆诊断装置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安装在壳体上，从而便于诊断人员将车辆诊断设备1000与车辆进行连接。适配用接口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完成对不同车辆的自动适配，提升了车辆诊断设备1000在车辆下线诊断过车中的通用性。

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

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

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

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

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

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

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

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

扩展接口模块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的诊断数据及相应结果进行数据导出工作。另外，USB接口也可以用于连接USB数据线，此时与Pogo Pin接口的作用类似，可以同时支持数据传输及充电。

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

以上为核心装置100的具体介绍，接下来对操作装置200做具体阐述：

操作控制模块220用于控制操作装置200中各硬件的运行，以及用于和诊断模块130共同执行诊断。

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

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

作为一种实施形态，本实施例的操作装置200还设有扫码器300。

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

交互组件400为车辆诊断设备1000在使用过程中所需要的提示灯、按键、扬声器等部件。

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

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

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

4个设置在操作装置200上的按键分别设置在第二壳体210的侧边，分别是用于增大和减小音量的两个音量调节按键、用于开关车辆诊断设备1000的开关机键以及针对操作装置200的Win键。

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

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

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

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

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

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

以上为车辆诊断设备在结构上的具体介绍，以下将参考图3对设置在车辆诊断设备1000上的跨平台车辆诊断系统2000做具体介绍。

操作系统层2001包括操作系统以及与诊断系统硬件1001相对应的驱动(诊断系统硬件1001即车辆诊断设备1000中的无线模组150、接口模块20、散热模块30、电源模块40、扩展接口模块50等硬件)。

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

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

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

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

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

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

本实施例中，应用层2004设置在操作装置200上，在核心装置100上运行的进程通信管理服务可以通过远程调用服务(如RPC服务)管理进程间通信。即，当诊断人员通过操作装置200的第二操作系统层2006运行诊断程序，该诊断程序在运行时产生的硬件调用请求通过远程调用服务发送给进程通信管理服务，随后进程通信管理服务对该硬件调用请求进行响应并进行后续通信处理。

在其他实施形态中，应用层2004还可以设置在数据服务器上，此时，进程通信管理服务也可以通过远程调用服务管理进程间通信，即，当数据服务器发送请求给核心装置100时进程通信管理服务就通过远程调用服务对请求进行响应并在后续通信过程中将数据反馈给数据服务器。

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

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

本实施例中，所有诊断程序设置在操作装置200中，诊断人员可以通过操作装置200的显示屏选定并执行需要执行的诊断程序。需要说明的是，本实施例中各预设服务也均设置在操作装置200中(即应用层2004全部地设置在操作装置200中)，但在实际应用中，应用层2004可以全部或部分地设置在诊断装置100、操作装置200、数据服务器或是其他计算设备上，例如，诊断程序和部分预设服务设置在操作装置200中、另一部分预设服务设置在诊断装置中，或者诊断程序设置在数据服务器中、预设服务设置在操作装置中等等，本跨平台车辆诊断系统所设计的应用层2004可以根据硬件条件灵活地设置在不同平台中。

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

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

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

作为一种实施形态，当诊断程序被运行从而执行车辆诊断操作时，该诊断程序将产生的硬件调用请求及其他相关调用请求会先通过进程通信管理服务发送给进程调用管理服务。

接下来，由进程调用管理服务根据硬件调用请求仲裁并分配相应类型的预设服务，并控制进程通信管理服务将硬件调用请求发送给预设服务对相应类型的硬件协议进行调用。

进一步地，当接收到进程通信管理服务发送的硬件调用请求时，各个预设服务根据当前接收到的所有硬件调用请求确定硬件调用策略，并根据该硬件调用策略对相应类型的硬件协议进行调用，从而使得诊断程序在诊断操作过程中完成对诊断系统硬件的控制。

其中，硬件调用策略具体包括：

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

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

若否，则直接处理该硬件调用请求；

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

此外，由于诊断程序需要对车辆进行诊断操作，因此当车辆进行通讯连接时，车辆通讯服务就会对网络协议栈和/或CAN协议栈进行调用从而完成核心装置100与车辆的通讯连接。接下来，一旦诊断程序执行车辆诊断操作并产生相应的车辆诊断数据，这些车辆诊断数据就会通过车辆通讯请求发送给车辆通讯服务，该车辆通讯服务根据当前接收到的所有车辆通讯请求确定通讯调用策略，并根据该通讯调用策略调用网络协议栈和/或CAN协议栈完成车辆诊断数据的传输。

在诊断操作过程中，进程调用管理服务还用于对车辆反馈的诊断结果进行收集并在中间层进行数据整合。

特别地，本实施例中，进程调用管理服务会对预设服务的运行进行监控，并在预设服务发生停止运行等失效行为时，根据预设逻辑智能地对预设服务的失效进行纠正。例如，可以有以下预设逻辑：

当进程通信管理服务将硬件调用请求发送给预设服务对相应类型的硬件协议进行调用时，进程调用管理服务对预设服务输出的数据包进行完整性校验；

若校验到数据包不完整，则请求相应的预设服务重新发送数据包并再次进行完整性校验直至校验到数据包完整；

若校验到数据包完整，则允许预设服务继续进行后续调用。

类似地，进程调用管理服务还会对各个协议的运行进行监控，并在各协议对硬件的调用发生停止运行等失效行为时，根据预设逻辑智能地对协议的失效进行纠正。例如，针对协议层2002的各个硬件协议，可以有以下预设逻辑：

当预设服务对硬件协议进行调用使其对诊断系统硬件进行控制时，进程调用管理服务对硬件协议中的硬件驱动标志位进行检测，从而判断硬件调用请求是否发生错误(例如，对硬件的启动信号、运行信号、停止信号进行检测，在检测到硬件没有一个完整的开始结束过程时判断硬件调用请求存在错误)；

当判断硬件调用请求发生错误时，根据预设逻辑对硬件协议的控制进行纠正；

当判断硬件调用请求没有错误时，则允许硬件协议继续进行后续调用。

本实施例中，针对硬件的预设逻辑可以为重启诊断系统硬件、等待诊断系统硬件响应、或上报硬件调用错误中的任意一种或多种。例如，可以有以下预设逻辑：

当判断硬件调用请求发生错误时，进程调用管理服务控制硬件协议再次发送硬件调用请求并在预设时间内等待诊断系统硬件的响应；

若预设时间内没有响应，则重启诊断系统硬件，并控制硬件协议重新发送硬件调用请求并等待预设时间；

若重启后在预设时间内没有响应，则判定此次任务失效，并向上层上报硬件调用错误，如发送错误报告给诊断人员。

可以理解的是，以上介绍了针对硬件调用的一种预设逻辑，但在实际应用中可以根据需求对该逻辑进行调整，例如仅在预设时间内等待诊断系统硬件的响应并在没有响应时上报错误，本实施例对此不作限制。

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

如图5所示，为便于说明，接下来以针对整车下线检测中，在车辆驾驶过程中进行雷达标定检测为例，对跨平台车辆诊断系统在诊断操作过程中的数据处理流程进行详细介绍：

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

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

操作装置200运行诊断程序，该诊断程序向核心装置100发送启动APP请求，进程通信管理服务通过RPC服务使得进程调用管理服务接收APP请求；

进程调用管理服务根据启动APP请求从应用层中确定APP需要调用的预设服务，并初始化预设服务；

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

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

需要说明的是，本实施例中的诊断程序在操作装置200中运行，因此进程通信管理服务需要通过RPC服务来接收APP请求。在其他实施形态中，若诊断程序在核心装置100上运行，则可以不需要RPC服务，进程通信管理服务可以直接将诊断程序产生的请求发送给进程调用管理服务。

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

操作装置200中的诊断程序产生通讯请求，进程通信管理服务通过RPC服务接收该通讯请求，进程调用管理服务控制车辆通讯服务获取该通讯请求；

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

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

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

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

进程调用管理服务控制车辆通讯服务用之前确定的通讯协议对诊断数据进行拆包/封包；

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

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

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

应用层2004的某一诊断程序(例如结果上传程序)检测到车辆诊断设备1000与数据服务器建立通讯连接，向进程调用管理服务发起上传请求；

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

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

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

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

还需说明的是，尽管上述实施例中，操作装置200与核心装置100存在物理连接形成一整个车辆诊断设备。但是在具体实施过程中，操作装置也可以是诊断人员持有的计算机或者数据服务器，本方案的跨平台车辆诊断系统及相关的车辆诊断流程依然可以实施，不受影响。

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

Claims (10)

1.一种跨平台车辆诊断系统，其特征在于；

包括设置在与待诊断的车辆相连接的核心装置上的：

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

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

中间层，设有进程调用管理服务以及进程通信管理服务，

还包括：

应用层，包括多个与所述硬件协议的类型相对应的预设服务以及至少一个诊断程序，该诊断程序用于对所述车辆执行诊断操作，

其中，所述应用层至少部分地设置在所述核心装置上，

所述应用层全部地设置在与所述核心装置相通信连接的第二装置上。

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

其中，每个所述预设服务独占一个进程，

当所述诊断程序执行所述诊断操作产生硬件调用请求时，由所述进程调用管理服务根据所述硬件调用请求仲裁并分配相应类型的所述预设服务，并控制所述进程通信管理服务将所述硬件调用请求发送给所述预设服务对相应类型的所述硬件协议进行调用，从而使得所述诊断程序在所述诊断操作过程中完成对所述诊断系统硬件的控制，

在所述诊断操作过程中，所述进程调用管理服务还用于对所述车辆反馈的诊断结果进行收集并在所述中间层进行数据整合。

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

所述应用层至少部分地设置在所述核心装置上，所述诊断操作为在车辆行驶过程中执行的标定操作，

当启动所述标定操作时，所述进程调用管理服务运行所述诊断程序，同时调用仲裁得到的所述预设服务进行初始化，使得协议层、操作系统层、诊断系统硬件逐层完成初始化并进入标定模式，

在进入标定模式后，

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

针对所述车辆反馈的诊断数据，所述操作系统层获取并对所述诊断数据进行整理和暂存，所述进程调用管理服务控制所述预设服务调用所述协议层对所述诊断数据进行拆包和/或封包，进一步发送给所述诊断程序进行业务逻辑处理判断。

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

所述应用层设置在与所述核心装置相通信连接的第二装置上，所述诊断操作为在车辆行驶过程中执行的标定操作，

所述第二装置还设有用于对所述诊断程序的人机交互功能进行支持的第二操作系统层，

当启动所述标定操作时，所述第二操作系统层运行所述诊断程序，产生的请求封装后通过所述进程通信管理服务发送给所述核心装置，

所述进程调用管理服务接收封装后的所述请求，并通过所述进程通信管理服务调用仲裁得到的所述预设服务进行初始化，

所述进程调用管理服务调用仲裁得到的所述预设服务进行初始化，使得协议层、操作系统层、诊断系统硬件逐层完成初始化并进入标定模式，

在进入标定模式后，

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

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

5.根据权利要求4所述的跨平台车辆诊断系统，其特征在于：

其中，所述进程通信管理服务支持有远程调用服务，

当所述第二操作系统层运行所述诊断程序时，该诊断程序在运行时产生的硬件调用请求通过所述远程调用服务发送给所述进程通信管理服务。

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

其中，当所述进程通信管理服务将所述硬件调用请求发送给所述预设服务对相应类型的所述硬件协议进行调用时，所述进程调用管理服务对所述预设服务输出的数据包进行完整性校验，

若校验到所述数据包不完整，则请求相应的所述预设服务重新发送所述数据包并再次进行所述完整性校验直至校验到所述数据包完整。

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

其中，当所述预设服务对所述硬件协议进行调用使其对所述诊断系统硬件进行控制时，所述进程调用管理服务对所述硬件协议中硬件的驱动标志位进行检测，从而判断所述硬件调用请求是否发生失效，

当判断所述硬件调用请求发生错误时，根据预设逻辑对所述硬件协议的控制进行纠正，

所述预设逻辑为控制所述硬件协议相硬件重新发起控制请求，并在预设时间内等待所述诊断系统硬件响应，

若预设时间内没有响应，则判定发生失效，并向上层上报硬件调用错误。

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

其中，在判定发生失效前，所述预设逻辑还包括：

重启诊断系统硬件，并控制硬件协议重新发送硬件调用请求并等待预设时间；

若重启后在预设时间内没有响应，判定发生失效。

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

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

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

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

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

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

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