CN116560721A - 车辆诊断系统、方法及电子设备 - Google Patents

Abstract

本申请提供了一种车辆诊断系统、方法及电子设备，车辆诊断系统包括：数据管理平台，存储有车辆在生命周期内的车辆订单数据；车辆生命周期包括多个生命场景，同一生命场景下的车辆订单数据存储在一起；程序开发平台，用于开发并存储各生命场景对应的诊断程序架构；设备管理平台，用于根据为管理的至少一个诊断设备确定各自对应的生命场景、及记录的诊断程序架构更新迭代的程序架构版本信息，分别对每个诊断设备进行功能配置，生成包含每个诊断设备的功能配置信息的设备功能配置表，并将设备功能配置表中功能配置信息发送至适配的诊断设备，诊断设备则根据收到的功能配置信息获取数据以备后续诊断车辆使用。本系统能兼容车辆全生命周期的诊断业务。

Description

车辆诊断系统、方法及电子设备

技术领域

本申请涉及车辆诊断技术领域，尤其涉及一种车辆诊断系统、方法及电子设备。

背景技术

随着车辆智能化的发展，车辆上硬件功能逐渐变得越来越复杂，整车软件也随着硬件功能需求不断地迭代更新。

通常，车辆的生命周期是包含有研发、制造、售后等多个生命场景的，在各个生命场景下往往都需要使用相应包含诊断设备的诊断系统对车辆进行诊断测试、故障分析、数据存档等。目前，现有诊断系统多是针对车辆的单一生命场景进行开发的，无法覆盖车辆整个生命周期，这致使车企在车辆的不同生命场景均需要各自投资开发相应的诊断系统，资源浪费严重；此外，由于针对不同生命场景所开发的不同诊断系统之间存在较大差异，使得无法很好的集中管理各诊断系统和快速协同变更诊断程序，以应对整车软件在不同生命场景下环环关联和快速迭代的需求。

发明内容

鉴于上述问题，本申请提供一种解决上述问题或至少部分地解决上述问题的一种车辆诊断系统、方法及电子设备。

在本申请的第一个实施例中，提供了一种车辆诊断系统。该车辆诊断系统包括：

数据管理平台，其内存储有车辆在生命周期内的车辆订单数据；其中，所述生命周期包括多个生命场景，同一所述生命场景下的车辆订单数据存储在一起；

程序开发平台，用于开发并存储各所述生命场景对应的诊断程序架构；

设备管理平台，用于为管理的至少一个诊断设备确定各自对应的所述生命场景；记录所述诊断程序架构更新迭代的程序架构版本信息；根据每个所述诊断设备对应的所述生命场景和所述程序架构版本信息，分别对每个所述诊断设备进行功能配置，以生成包含每个所述诊断设备的功能配置信息的设备功能配置表；将所述设备功能配置表中的功能配置信息发送至适配的诊断设备；

至少一个诊断设备，所述诊断设备用于根据接收到的所述功能配置信息，分别从所述程序开发平台、所述数据管理平台中获取并存储相应的诊断程序架构、车辆订单数据，以备后续在对与所述诊断设备连接的车辆进行诊断时使用。

在本申请的第二实施例中，还提供了一种车辆诊断方法。该方法适用于设备管理平台。所述方法包括：

为管理的至少一个诊断设备确定各自对应车辆的生命场景，其中，所述车辆生命周期包含多个生命场景；

记录程序开发平台中所存储的诊断程序架构更新迭代的程序架构版本信息；其中，程序开发平台中存储有所述多个生命场景中各生命场景对应的诊断程序架构；

根据每个诊断设备对应车辆的所述生命场景和所述程序架构版本信息，分别对每个诊断设备进行功能配置，生成包含每个诊断设备的功能配置信息的设备功能配置表；

将所述设备功能配置表中的功能配置信息发送至适配的诊断设备，以便所述诊断设备根据接收到的所述功能配置信息，获取相应的数据以备在诊断车辆时使用。

在本申请的第三实施例中，还提供了一种车辆诊断方法。该方法适用于数据管理平台；所述方法包括：

从数据提供端获取车辆在生命周期中不同生命场景下产生的车辆数据信息、以及整车软件的版本基线包；

基于所述版本基线包中包含的车辆器件标识与整车软件版本标识的对应关系、以及所述车辆数据信息中车辆数据携带的车辆器件标识，将所述版本基线包与所述车辆数据信息进行匹配，生成多个包含整车软件版本标识与车辆数据的车辆订单数据；

按照各车辆订单数据中车辆数据对应的所述生命场景，将各车辆订单数据进行存储，以备后续为诊断设备提供所需的车辆订单数据；

其中，所述诊断设备是根据从设备管理平台接收到的功能配置信息，向数据管理平台获取所需的车辆订单数据的；所述设备管理平台通过执行上述本申请第二实施例中提供的车辆诊断方法中的步骤向所述诊断设备发送适配的功能配置信息。

在本申请的第四实施例中，还提供了一种车辆诊断方法。该方法适用于程序开发平台；所述方法包括：

接收数据提供端发送的诊断数据文件；其中，所述诊断数据文件是针对车辆生命周期开发诊断程序架构时所需依据的数据文件，所述诊断数据文件中包含诊断服务信息，所述生命周期包括多个生命场景；

对所述诊断数据文件进行解析，得到多个诊断服务；

从所述多个诊断服务中，确定各生命场景需要使用的至少一个诊断服务；

根据各生命场景需要使用的至少一个诊断服务，生成各生命场景对应的诊断程序架构，以备后续为诊断设备诊断车辆提供所需的诊断程序架构；

其中，所述诊断设备是根据从设备管理平台接收到的功能配置信息，向程序开发平台获取所需的诊断程序架构的；所述设备管理平台通过执行上述本申请第二实施例中提供的车辆诊断方法中的步骤向所述诊断设备发送适配的功能配置信息。

本申请实施例提供的技术方案，车辆诊断系统包括设备管理平台、数据管理平台、程序开发平台、诊断设备。车辆生命周期是包含有多个生命场景的，上述设备管理平台能为管理的至少一个诊断设备确定各自对应车辆的生命场景，并记录程序开发平台中所存储的各生命场景诊断程序架构更新迭代的程序架构版本信息，从而根据每个诊断设备对应车辆的生命场景和所述程序架构版本信息，分别对每个诊断设备进行功能配置，以生成包含每个诊断设备的功能配置信息的设备功能配置表，进而将设备功能配置表中的功能配置信息发送至适配的诊断设备。可见，本方案通过上述设备管理平台能实现批量配置用于诊断不同生命场景下的诊断设备的功能配置信息，可有效实现不同诊断设备的功能差异化，满足不同生命场景车辆的诊断需求。上述数据管理平台在从数据提供端获取到车辆在生命周期中不同生命场景下产生的车辆数据信息、以及整车软件的版本基线包后，可基于版本基线包中包含的车辆器件标识与整车软件版本标识的对应关系、以及所述车辆数据信息中车辆数据携带的车辆器件标识，将版本基线包与车辆数据信息进行匹配，生成多个包含整车软件版本标识与车辆数据的车辆订单数据，并按照各车辆订单数据中车辆数据对应的生命场景，对各车辆订单数据进行存储，以备后续为诊断设备提供所需的车辆订单数据。可见，本方案通过上述数据管理平台按生命场景实现了对车辆各生命场景下产生的车辆数据下统筹整合管理，有助于精准地为诊断设备提供所需的数据。上述程序开发平台，在经解析接收到的诊断数据文件，解析出多个诊断服务后，可从该多个诊断服务中确定各生命场景需要使用的至少一个诊断服务，并根据各生命场景需要使用的至少一个诊断服务，生成各生命场景对应的诊断程序架构，以备后续为诊断设备诊断车辆提供所需的诊断程序架构。利用本方案提供的程序开发平台开发诊断程序，在应对车辆生命周期的多个生命场景时，能有效降低程序开发周期和成本、减少程序重复开发、资源浪费等。综上，本申请提供的车辆诊断系统，具有较高的灵活程度和自动化程度，能兼容车辆全生命周期的诊断业务，可有效减少设备投资、降低诊断成本等。

附图说明

为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要利用的附图作一简单地介绍，显而易见地，下面描述中的附图是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1为本申请实施例提供的一种车辆诊断系统的结构示意图；

图2a为本申请实施例提供的车辆诊断系统中设备管理平台的结构示意图；

图2b为本申请实施例提供的设备管理平台的交互界面示意图；

图3a为本申请实施例提供的车辆诊断系统中数据管理平台的结构示意图；

图3b为本申请实施例提供的数据管理平台的交互界面示意图；

图4a为本申请实施例提供的车辆诊断系统中程序开发平台的结构示意图；

图4b为本申请实施例提供的利用程序开发平台针对车辆不同生命场景开发设计相对应的诊断程序架构的原理性示意图；

图4c为本申请实施例提供的程序开发操作界面示意图；

图5为本申请实施例提供的车辆诊断系统中诊断设备的结构示意图；

图6至图8为本申请实施例提供的车辆诊断方法的流程示意图；

图9为本申请实施例提供的电子设备的结构示意图；

图10为本申请实施例提供的计算机程序产品的结构示意图。

具体实施方式

车辆的生命周期包含有研发、制造（生产制造）、售后等多个生命场景，在各个生命场景下常都需要使用相应包含诊断设备的诊断系统对车辆进行诊断测试、故障分析、数据存档等。车辆在各生命场景下诊断要求的关联度和逻辑性往往要求比较高，比如，在研发场景时诊断车辆产生的诊断测试数据需存档传递至制造场景进行应用，制造场景时诊断车辆产生的诊断测试数据又需存档传递至售后场景进行应用，同时售后场景维修车辆产生的维修数据又需传递至研发场景以协助整车软件的修复迭代等。

在车辆诊断技术领域中现存的诊断系统，基本上都是针对车辆单一的生命场景进行开发的，诊断系统的诊断功能较为单一，所能够适用的车辆生命场景具有很大的局限性，无法覆盖车辆生命周期中的多个生命场景，为此各车企在车辆的研发、制造、售后等不同生命场景均需各自投资开发诊断系统，存在开发成本高、资源浪费严重等的问题。另外，诊断系统需对接的任务常比较复杂，涵盖有车辆的BOX（Bill of Materials，物料清单）数据、整车软件、诊断ODX（Open diagnostic data exchange，开放式的诊断数据格式）文件等，而针对车辆的不同生命场景所开发出的不同诊断系统之间的数据种类、格式要求、交互时机等往往具有较大差异，由此致使不同生命场景对应的不同诊断系统之间仅能通过接口进行基础的数据传递，无法通过接口连接实现车辆的多生命场景诊断，也无法通过单一的诊断系统来实现车辆的多生命场景诊断。此外，在车辆的不同生命场景下所需要检测的车辆状态、所需的整车软件资源等也常都是不相同的，由于目前无法做到集中管理针对车辆的不同生命场景所开发的不同诊断系统、以及快速协同变更系统中相应的诊断程序，从而造成难以自动快速批量调整诊断系统中诊断设备的配置、识别出诊断所需的车辆信息等，以及也难以调度到准确的诊断程序和整车软件对车辆器件（如控制器）进行功能检测。综上，现存诊断系统无法应对多生命场景的车辆诊断需求，所以急需一套综合性的车辆诊断系统来统筹处理、调度、分配及存储数据等以应对多生命场景的车辆诊断需求。

需补充说明的是：上述ODX文件是一种标准架构诊断数据文件，简单的也就是说，是一种开放式的诊断数据格式标准化的诊断数据文件，用于描述车辆诊断相关数据，如通信协议信息、诊断服务信息等，其在车辆生命周期中的如研发、制造、售后等不同生命场景中传递交互时，无需进行格式转换、可使得车辆诊断整个流程实现更容易、快速、出错率较低。

为解决上述技术问题，本申请各实施例提供的一种新的车辆诊断技术方案，能够兼容车辆全生命周期的多个生命场景诊断需求，减少诊断成本以及资源浪费等。

为了使本技术领域的人员更好地理解本申请方案，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述。

在本申请的说明书、权利要求书及上述附图中描述的一些流程中，包含了按照特定顺序出现的多个操作，这些操作可以不按照其在本文中出现的顺序来执行或并行执行。操作的序号如101、102等，仅仅是用于区分各个不同的操作，序号本身不代表任何的执行顺序。另外，这些流程可以包括更多或更少的操作，并且这些操作可以按顺序执行或并行执行。需要说明的是，本文中的“第一”、“第二”等描述，是用于区分不同的消息、设备、模块等，不代表先后顺序，也不限定“第一”和“第二”是不同的类型。而本申请中术语“或/和”，仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如：A或/和B，表示可以单独存在A，同时存在A和B，单独存在B这三种情况；本申请中字符“/”，一般表示前后关联对象是一种“或”关系。还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的商品或者系统不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种商品或者系统所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的商品或者系统中还存在另外的相同要素。此外，下述的各实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

下面对本申请各实施例提供的技术方案进行详述。

本申请下文各实施例中所涉及的车辆，可以是纯电动车、燃油车、混合车等，本申请对此不作限定。

图1示出了本申请一实施例提供的车辆诊断系统的结构示意图。如图1所示，本申请实施例提供的车辆诊断系统包括：数据管理平台10、程序开发平台20、设备管理平台30以及至少一个诊断设备40；其中，

数据管理平台10，其内存储有车辆在生命周期内的车辆订单数据；其中，所述生命周期包括多个生命场景，同一所述生命场景下的车辆订单数据存储在一起；

程序开发平台20，用于开发并存储各所述生命场景对应的诊断程序架构；

设备管理平台30，用于为管理的至少有一个诊断设备确定各自对应的所述生命场景；记录所述诊断程序更新迭代的程序架构版本信息；根据每个所述诊断设备对应的所述生命场景和所述程序架构版本信息，分别对每个所述诊断设备进行功能配置，以生成包含每个所述诊断设备的功能配置信息的设备功能配置表；将所述设备功能配置表中的功能配置信息发送至适配的诊断设备；

至少一个诊断设备40，所述诊断设备用于根据接收到的所述功能配置信息，分别从所述程序开发平台、所述数据管理平台中获取并存储相应的诊断程序架构、车辆订单数据，以备后续在对与所述诊断设备连接的车辆进行诊断时使用。

上述数据管理平台10、程序开发平台20等内存储的车辆订单数据、诊断程序架构，是基于车辆诊断系统向上承接的数据提供端提供的相应数据来生成实现的。数据提供端可包括但不限于：车辆研发中心、车辆制造中心、车辆售后中心、研发数据库、整车软件中心、安全认证中心等。具体地，

上述车辆研发中心用于就车辆研发过程中产生的车辆数据信息与数据管理平台进行数据交互，车辆制造中心用于就车辆制造过程中产生的车辆数据信息与数据管理平台进行数据交互，车辆售后中心用于就车辆售后过程中产生的车辆数据信息与数据管理平台进行数据交互。例如，线下车辆研发部门的研发人员在研发车辆过程中将相应产生的车辆数据上传至数据提供端后，数据提供端便会将该车辆数据发送至车辆研发中心以存储，车辆研发中心就接收到的车辆数据可以定时或实时的向数据管理平台主动推送，或者车辆研发中心也可以等待数据管理平台来拉流以被动推送车辆数据。数据管理平台基于通过与上述车辆研发中心、车辆制造中心及车辆售后中心获取到的车辆数据，可生成相应的多个车辆订单数据。有关车辆订单数据具体的生成实现，将在下文详述数据管理平台时有展开详述，此处不作具体赘述。

上述研发数据库用于提供开发诊断程序架构需依赖的诊断数据文件，其中，诊断数据文件可以为但不限于ODX文件，其内标准化定义了车辆诊断需使用的诊断服务信息、通信协议信息、数据格式等。

上述安全认证中心（PKI，Public Key Infrastructure），用于提供证书、密钥管理和分配等服务，能够为所有的网络应用提供加密和数据签名等密码服务及所需要的密钥和证书的管理。在本实施例中，上述安全认证中心（PKI）主要是用于为车辆的不同生命场景诊断安全需求提供相应的安全认证数据，并会向设备管理平台推送安全认证数据的版本更新信息，以为设备管理平台为所管理的诊断设备进行功能配置提供数据支持。即，设备管理平台为诊断设备配置的功能配置信息中还可包括安全认证数据版本，诊断设备可按照其对应的功能配置信息中的安全认证数据版本去安全认证中心获取并存储相应版本的安全认证数据，以备后续在监测到诊断技术人员通过诊断设备提供的诊断应用触发了诊断启动操作后，可验证该诊断技术人员是否有诊断权限等。其中，安全认证数据可以为但不限于密钥证书等。

上述整车软件中心（VSP）是用于管理车辆的整车软件，具体地，可采用软件版本基线方式来管理针对车辆在不同时期发布的不同版本的整车软件；其中，整车软件中包含车辆中各车辆器件功能实现所需的软件，每次按需求升级整车软件中的某一个或几个软件，同时都会检查一下整车软件中除该某一个或几个软件之外的其它软件是否需要做相应的升级变化以保证各软件之间的兼容性，为此对整车软件是作整车迭代更新的。整车软件中心在采用软件版本基线方式管理不同版本的整车软件时，会按照迭代更新时间建立相应的软件版本基线，不同的软件版本基线会按时间顺序排列以此会形成一个软件版本基线序列。上述软件版本基线中含有车辆器件与整车软件的对应关系，可实现车辆器件与整车软件的同步管理。

例如，结合下表1，假设针对车辆研发阶段建立的一个软件版本基线为软件版本基线GX_V1.0，软件版本基线GX_V1.0中的诸如TBOX（Telematics Box，车联网系统）与Soft_V1.0对应，表示车辆上的车联网系统适合使用Soft_V1.0版本整车软件。之后，在车辆生产制造阶段，对车辆上的车联网系统以及网关（GW）等需做硬件功能升级，为此针对此需求对整车软件做了相应的迭代更新，整车软件从版本Soft_V1.0更新为版本Soft_V2.0，按照此次迭代更新时间会建立有相应的软件版本基线GX_V1.1，软件版本基线GX_V1.1排列在软件版本基线GX_V1.0之后。需补充说明的是：ADAS表示车辆上的高级辅助驾驶系统。

表1

基于上述所述内容即，本实施例提供的所述车辆诊断系统通信连接有数据提供端，所述数据提供端能提供的数据包括：车辆在生命周期中不同生命场景下产生的车辆数据、整车软件、诊断不同生命场景下车辆所需使用的安全认证信数据、开发诊断程序架构所需依据的诊断数据文件，其中，所述诊断数据文件中包含诊断服务信息。上述数据提供端可以为但不限于云端，其会向车辆诊断系统中各平台和/或设备发送相应的数据信息，以为各平台和/或设备实现相应的功能提供数据支持。

比如，数据提供端（更具体地为整车软件中心、安全认证中心）会向设备管理平台分别针对整车软件、安全认证数据推送相应的版本更新信息，以为设备管理平台对各诊断设备进行功能配置提供数据支持。

以及，如参见图2示出的设备管理平台30的结构示意图，上述设备管理平台30包括：接收模块31、场景配置模块32、功能配置模块33及发送模块34；其中，

接收模块31，用于接收所述程序开发平台针对诊断程序架构发送的版本更新信息，以及还用于接收所述数据提供端分别针对整车软件、安全认证数据发送的版本更新信息，并根据接收到的各版本更新信息，记录诊断程序架构更新迭代的程序版本信息、整车软件更新迭代的软件版本信息、安全认证数据更新迭代的认证数据版本信息；

场景配置模块32，用于响应于对所述至少一个诊断设备触发的场景配置管理操作，为每个诊断设备配置对应的所述生命场景；

功能配置模块33，用于根据每个诊断设备对应的所述生命场景、所述程序架构版本信息、所述软件版本信息及所述认证数据版本信息，分别对每个诊断设备进行功能配置，以生成包含每个诊断设备的功能配置信息的设备功能配置表；

发送模块34，用于将所述设备功能配置表中的功能配置信息发送至适配的诊断设备。

上述中，程序开发平台发送版本更新信息的时机可以是监测到开发人员对诊断程序触发了更新操作，且其针对诊断程序架构所发送的版本更新信息至少包括诊断程序架构版本标识、诊断程序架构对应生命场景的场景标识，此外还可包括诊断程序架构版本的版本时间等。当然，程序开发平台也可以定时或实时向设备管理平台针对诊断程序架构发送相应的版本更新信息。有关数据提供端向发送相应的版本更新信息的时机、版本更新信息中可包括的信息内容、可参见上述针对程序开发平台发送相应的版本更新信息所详述的内容。

接收模块31根据接收到的各版本更新信息，记录相应更新迭代的诊断程序架构的程序架构版本信息、整车软件的软件版本信息以及安全认证数据的认证数据版本信息等时，对应的记录格式可为：[生命场景标识：程序架构版本信息：软件版本信息、认证数据版本信息]，其中，诸如程序架构版本信息可包括但不限于：版本标识、版本时间。通过上述记录，实现了按生命场景，将程序架构版本信息、软件版本信息、认证数据版本信息等进行分组记录，能为后续功能配置模块快速查找获知在某一生命场景下能使用哪些版本的诊断程序架构、整车软件、安全认证数据等以对相应的诊断设备进行功能配置提供便利。此外，将上述记录内容还可以通过设备管理平台前端的显示模块进行显示给相应的用户，使得用户可从视觉上清晰明了的了解到在某一生命场景下能使用哪些版本的诊断程序架构、整车软件、安全认证数据等来对相应的诊断设备进行功能配置。

这里需要补充说明的是，本实施例提供的车辆诊断系统中的数据管理平台也可向设备管理平台针对车辆订单数据发送相应的更新信息，以通知设备管理平台其内存储的车辆订单数据发生了变更，使得设备管理平台可对数据管理平台的数据更新时间进行记录，以便用户通过设备管理平台也可了解到数据管理平台的数据更新动态变化。另外，上述设备管理平台中设置有针对接收到的数据自动响应规则，按照该自动相应规则，设备管理平台在接收到程序开发平台、数据管理平台、数据提供端等发送的更新信息后，可作相应的反馈响应。例如，可向程序开发平台发送反馈响应信息1、向数据管理平台发送反馈响应信息2、向数据提供端发送反馈响应信息3等。

上述接收模块31所记录的信息可以通过自动模块定时或实时的向功能配置模块33下发。例如，自动模块根据自身内预置的信息获取逻辑，可以定时从接收模块中获取到其所记录的信息并下发给功能配置模块33。当然，接收模块31也可主动向自动模块推送所记录的信息，本实施例对此不作限定。此外，考虑到发送至设备管理平台的信息可能会是异常信息，比如为不在所需范围内的更新信息，具体地除数据提供端、程序开发平台、数据管理平台之外的其他设备发送的异常更新信息，针对异常信息是否需要接收可通过人工模块交由人工干预来处理。比如，人工模块监测到发送至设备管理平台的信息为异常信息后，可输出一提示信息给相应的用户，以便用户根据该提示信息做出对该异常更新信息的人工处理，如允许接收、拒绝接收等；若人工模块确定用户做出允许接收的决定，则可通知接收模块针对该异常信息进行正常接收处理；若人工模块确定用户做出拒绝接收的决定，则可通知接收模块将该异常信息作为垃圾信息进行拒接。由上内容即，上述设备管理平台30还可包括：自动模块，用于将接收模块记录的信息自动推送给功能配置模块33；人工模块，用于在监测到接收模块接收到异常信息时，输出提示信息，以提示用户对所述异常信息进行人工处理。其中，提示信息可为语音、图片、文字中的一种或组合，在提示信息包含图片和/或文字时，图片和/或文字可通过设备管理平台对应的显示模块进行呈现给用户。

上述场景配置模块32，在响应于对至少一个诊断设备触发的场景配置管理操作，为每个诊断设备确定所配置的生命场景后，可按生命场景对诊断设备进行分组管理。

在本实施例提供的车辆诊断系统中，所包括的至少一个诊断设备往往会来自不同的渠道，比如有些诊断设备可能是归属于A地区，有些诊断设备可能是归属于B地区中某个工厂的某个工位等等，对来自不同渠道的诊断设备具体属于什么功能、用于诊断什么生命场景下的车辆等，需要用户做相应的定义以便分组管理，从而后续功能配置模块33在为诊断设备配置功能时，才能确定可为诊断设备配置哪些功能信息。对诊断设备的功能、用于诊断什么生命场景下的车辆等的定义，可由用户通过设备管理平台提供的场景配置管理交互界面来实现，该场景配置管理交互界面可通过设备管理平台前端的显示模块进行显示。

例如，参见图2b示出的一场景配置管理交互界面，以名称为设备3的诊断设备为例为例，用户针对名称为设备3的诊断设备点击了相应的生命场景设置标识（针对生命场景设置示出的三角形）后，会显示出一包含有多个生命场景项的车辆生命场景列表，若用户对车辆生命场景列表中的制造场景项触发了选择操作，则用户为IP地址为192.168.20.18、名称为设备3的诊断设备所定义的诊断车辆的生命场景便为制造场景。以此类推，也可针对其他诊断设备完成诊断车辆的生命场景定义配置。场景配置模块32根据用户对各诊断设备的定义配置，可按生命场景对诊断设备进行分组管理，具体地，如表2所示，可将对应相同生命场景的诊断设备的设备信息存储在一个分组内。

表2

上述功能配置模块33，可先根据每个诊断设备的IP地址，从场景配置模块32按生命场景对诊断设备进行分组管理所存储的设备信息（如表2所示）中，查询到每个诊断设备对应的生命场景，然后再根据每个诊断设备对应的生命场景，从接收模块31记录的信息中确定为每个诊断设备配置的整车软件版本、安全认证数据版本、诊断程序架构版本等，完成每个诊断设备的功能配置，从而生成包含每个诊断设备的功能配置信息表。

例如，承接上述结合图2b描述的示例，仍以名称为设备3的诊断设备为例，该名称为设备3的诊断设备对应诊断车辆的生命场景为制造场景，假设上述接收模块31中针对制造场景所记录的相应版本信息包括：诊断程序架构的版本标识包括版本Dig_V2.0，整车软件的版本标识包括：Soft_V2.0、Soft_V2.1、安全认证数据的版本标识包括：Ident_V2.0；其中，Soft_V2.1标识的是最新迭代后的整车软件，则针对名称为设备3的诊断设备进行功能配置时，可为其配置Dig_V2.0版诊断程序架构、Soft_V2.1版整车软件、Ident_V2.0版安全认证数据。

下表3为示出的功能配置信息表示例，表3中诊断设备标识可以是诊断设备的IP地址、诊断设备名称等，此处不作限定。

表3

之后，上述发送模块34可将上述功能配置信息表中的功能配置信息，通过相应的端口（如TCP端口）下发至适配的诊断设备；诊断设备则可根据接收到的功能配置信息，与数据提供端、数据管理平台、程序开发平台等进行交互，获取所需版本的数据，以用于车辆诊断。

这里需补充说明的是：功能配置模块33可根据接收模块31中所记录的信息、场景配置模块32所分组管理的设备信息等的更新变化，对功能配置信息表中相应诊断设备的功能配置信息进行更新，并通过发送模块34下发至相应的诊断设备。

本实施例通过在诊断系统后台所搭建的设备管理平台，可通过网络管理用于不同生命场景下的各类型诊断设备，具体地，设备管理平台可通过收集系统内其他平台或系统外部的数据提供端的更新信息，提前批量配置用于诊断不同生命场景下的诊断设备的功能配置信息（为诊断设备功能关键参数），再将功能配置信息准确下发至适配的诊断设备，从而实现不同诊断设备的功能差异化，满足不同生命场景车辆的诊断需求。

进一步地，上述数据管理平台10，主要作用按生命场景管理相应的数据。图3a示出了数据管理平台10的结构示意图。如参见图3a所示，上述数据管理平台10包括：处理模块11和多个场景车辆订单数据库12；其中，一个场景车辆订单数据库用于存储一个所述生命场景下的车辆订单数据。

处理模块11，用于从数据提供端获取车辆在生命周期中不同生命场景下产生的车辆数据信息、以及整车软件的软件版本基线包；基于所述软件基线包中包含的车辆器件标识与整车软件版本标识的对应关系、以及所述车辆数据信息中车辆数据携带的车辆器件标识，将所述软件版本基线包与所述车辆数据信息进行匹配，生成多个包含整车软件版本标识与车辆数据的车辆订单数据；按照所述车辆订单数据中车辆数据对应的所述生命场景，将各车辆订单数据存储至适配的场景车辆订单数据库中；

除上之外，数据管理平台10还可包括交互接口，如交互接口151和交互接口152，数据管理平台10通过交互接口151与数据提供端进行数据交互、通过交互接口152与诊断设备进行数据交互。由此，上述处理模块11在用于从数据提供端获取相应的车辆数据信息、软件版本基线包时，具体可用于：

通过交互接口151接收数据提供端推送的车辆在生命周期内不同生命场景下场景的车辆数据信息；其中，车辆数据信息中包含的车辆数据可以为但不限于：车辆识别码（VIN码）、车辆配置信息（比如各车辆器件（如控制器）的配置信息）、车辆器件信息等，车辆数据中可携带有车辆器件标识、生命场景标识；生命场景标识可以是任何能反映车辆数据对应生命场景的标识，比如，若一车辆数据具体是由数据提供端中的车辆研发中心推送过来的，则该车辆数据中携带的场景标识可为车辆研发中心的标识；或者也可以专门针对研发场景设置的标识，如上文所述的Research_S1。

通过交互接口151接收数据提供端（具体地为整车软件中心）针对软件版本基线推送的更新信息，该更新信息中可携带有其最新建立的软件版本基线对应的软件版本基线基线包，比如结合上述所述的表1，更新信息中可携带的是软件版本基线GX_V1.1对应的软件版本基线包，该软件版本基线包中含有车辆器件标识与整车软件版本标识的对应关系。

之后，处理模块11在针对车辆数据信息和软件版本基线包作匹配处理时，可具体用于：基于软件基线包中包含的车辆器件标识与整车软件版本标识的对应关系、以及车辆数据信息中车辆数据携带的车辆器件标识，将软件版本基线包中的各整车软件版本与车辆数据信息中的各车辆数据进行匹配，进而将对应有相同车辆器件标识的整车软件版本与车辆数据建立对应关系，以此生成多个包含整车软件版本标识与车辆数据的车辆订单数据。以及，在用于按照车辆订单数据中车辆数据对应的所述生命场景，将各车辆订单数据存储至适配的场景车辆订单数据库中时，具体可用于：根据各车辆订单数据中车辆数据携带的生命场景标识，为各车辆订单数据确定对应的生命场景，从而按照各车辆订单数据对应的生命场景，将各车辆订单数据存储至适配的场景车辆订单数据库中。

例如，如图3a，假设多个车辆订单数据库包括：研发场景车辆订单数据库、制造车辆订单数据库、售后车辆订单数据库，其中，研发场景车辆订单数据库关联有研发场景标识、制造车辆订单数据库关联有制造场景标识、售后车辆订单数据库关联有售后场景标识；以及接收到车辆研发中心推送过来的车辆数据a1，车辆制造中心推送过来的车辆数据b1、车辆数据b2，其中，车辆数据a1和车辆数据b1携带的车辆器件标识为TBOX、车辆数据b2携带的车辆器件标识为ADAS，以及结合上文所给出的表1，接收到整车软件中心针对软件版本基线GX_V1.1推送的软件版本基线包，则以车辆数据a1为例，基于软件版本基线包中包含的车辆器件标识和整车软件版本标识的对应关系，以及车辆数据a1携带的车辆器件标识，可生成一个包含整车软件版本标识Soft_V2.0和车辆数据a1的车辆订单数据Sa1，并按照车辆数据a1对应的研发场景，将该车辆订单数据Sa1存入至关联有研发场景标识的研发场景车辆订单数据库中。依次类推，针对车辆数据b1、车辆数据b2，可分别生成一个包含整车软件版本标识Soft_V2.0和车辆数据b1的车辆订单数据Sb1、一个包含整车软件版本标识Soft_V1.0、Soft_V2.0和车辆数据b2的车辆订单数据Sb2，并按照车辆数据b1和车辆数据b2对应的制造场景，将车辆订单数据Sb1和车辆订单数据b2均存入至关联有制造场景标识的制造场景车辆订单数据库中。

上述多个场景车辆订单数据库中存储的车辆订单数据，可为诊断设备诊提供相应所需的车辆订单数据，以备用于诊断车辆。

需要补充说明的是：由于车辆数据是由相应的车辆器件产生的，为此上述生成车辆订单数据的过程，实际上也就可视为将软件（整车软件）和车辆器件进行映射（Mapping）过程，可为后续向诊断设备下发精准的车辆订单数据提供依据。一车辆上的车辆器件，根据不同生命场可能Mapping不同版本的整车软件。

继续参见图3a，上述数据管理平台10还可包括：多个场景测试结果数据库13和查询模块14；其中，

一个场景测试结果数据库用于存储一个所述生命场景下对车辆诊断的诊断测试结果；

查询模块14，用于响应于查询操作，确定查询参数；根据所述查询参数，在适配的所述场景测试结果数据库或所述场景车辆订单数据库中执行查找，获得查找结果。

具体实施时，诊断设备在完成车辆诊断后产生的诊断测试结果，会通过交互接口152按照相应的生命场景回传至数据管理平台中相应的场景测试结果数据库。例如，若一诊断设备是用于诊断研发场景下的车辆，则该诊断设备诊断车辆产生的诊断测试结果便会回传至关联有研发场景标识的研发测试结果数据库。

为了便于用户查询数据管理平台所管理的数据，该数据管理平台还提供有查询功能。例如，在用户通过本车辆诊断系统提供的前端交互界面（Web界面）触发了数据管理平台对应的“数据管理”控件后，此时会通过显示模块显示出如图3b示出的数据查询界面，用户在该数据查询界面上可输入相应的查询参数，比如数据对应的生命场景（如研发、制造、售后等）、数据类型（如车辆订单数据、测试结果数据）、数据所属时间范围等，输入完成后，可点击“立即查询”控件，查询模块14响应于用户对“立即查询”控件，触发的点击操作，便会按照用户输入的查询参数在相应的数据库中执行查找，若查找到符合查询参数要求的数据，可将查找到的数据再通过显示模块显示给用户；若未查找到符合查询参数要求的数据，可输出提示信息以提示用户未查找到匹配的数据。

本实施例通过在车辆诊断系统后台所搭建的数据管理平台，可实现对诊断各生命场景所需使用到的车辆数据进行统筹整合管理，并能精准下发至相应不同生命场景对应的诊断设备，以供诊断设备诊断相应生命场景下的车辆时使用；同时，还会收集诊断设备诊断车辆产生的诊断测试结果，并按生命场景进行分类存储，这使得数据管理能覆盖整个产品生命周期，有效形成数据闭环关联。

进一步地，上述程序开发平台20，主要作用是提供程序开发功能，并存储通过该程序开发功能所开发出的每个所述生命场景对应的诊断程序架构。具体实施时，程序开发功能可通过程序开发平台20中的各功能模块相协助来实现。

图4a示出了上述程序开发平台20的结构示意图。如参见图4a，上述程序开发平台20包括：解析模块21和编辑模块22；其中，

解析模块21，用于对从所述数据提供端获取到的诊断数据文件进行解析，得到多个诊断服务；

编辑模块22，用于从所述多个诊断服务中，确定各所述生命场景需要使用的至少一个诊断服务；根据各所述生命场景需要使用的至少一个诊断服务，生成各所述生命场景对应的所述诊断程序架构。

上述中，数据提供端（具体地为研发数据库）可定期向程序开发平台20推送文件更新信息，该文件更新信息中包含有更新后的诊断数据文件，从而实现将诊断数据文件下发至程序开发平台20。程序开发平台20将接收到的诊断数据文件会先交由自身内的解析模块21进行解析处理，以从诊断数据文件中解析拆解出多个单条的诊断服务。

具体实施时，上述诊断数据文件可以是但不限于ODX文件，有关诊断数据文件的详述，可参见上文相关内容。相应地，解析模块21与诊断数据文件适配，可以为但不限于ODX解析器。ODX解析器在对ODX文件解析时，会通过从ODX文件中找到的DIAG-SERVICE（诊断通信服务）元素，来获取车辆中各控制器等车辆器件所能支持的多个诊断服务，从而再把该多个诊断服务展示给用户（如程序开发人员），具体地，可通过程序开发平台20提供的操作界面来实现展示。操作界面是程序开发平台提供的供用户进行程序开发使用的交互界面。由上即，上述程序开发平台20还可包括：操作界面23，用于显示所述多个诊断服务；

用户在通过操作界面23针对车辆生命周期中不同生命场景进行诊断程序开发时，可从操作界面23上显示的多个诊断服务中，分别针对各生命场景选择相应所需使用的至少一个诊断服务。由此，令目标生命场景为多个生命场景中的一个，则：

上述编辑模块22，在用于从所述多个诊断服务中，确定目标生命场景需要使用的至少一个诊断服务时，具体用于：

响应于针对目标生命场景对所述多个诊断服务触发的选择操作，确定目标生命场景需要使用的至少一个诊断服务。

例如，用户通过本车辆诊断系统提供的前端交互界面（Web界面）触发了程序开发平台对应的“程序开发”控件后，进入如图4c示出的程序开发平台提供的操作界面，并通过该操作界面车辆的研发场景进行诊断程序开发。具体地，假设用户当前正在通过操作界面针对研发场景进行诊断程序开发，其采用诸如拖拽等的方式，将操作界面上显示的多个诊断服务中的诊断服务14、诊断服务17及诊断服务15等拖拽至了编辑区相应的位置，则此时编辑模块22便将诊断服务14、诊断服务17及诊断服务15等确定为研发场景所需使用的至少一个诊断服务。

上述操作界面除了能显示多个诊断服务外，还可显示程序开发时所需使用到函数库中的多个函数，该多个函数能为用户实现每个生命场景对应的诊断程序架构的快速搭建提供底层函数支持。上述函数库为底层通用的函数库（Library Element库）。考虑到现有车企基本上都是采用平台化造车，平台化造车可使得车辆器件通用率高，能有效减少造车成本、提高造车效率，比如，通常车辆上具有五十多个控制器，两个不同车型车辆上所共有的控制器可能就会有三十多个，基于此，为了能节约程序开发成本、提高程序开发的效率，通过本实施例提供的程序开发平台20，用户可利用诊断服务和函数库中的多个函数，先从车辆器件层级上构建诊断程序，然后再基于从车辆器件层级上构建的诊断程序，进行诊断程序车型化，获得不同种车型对应的车型诊断，从而获得的不同种车型对应的车型诊断程序来得到相应生命场景对应的诊断程序架构。由此即，上述编辑模块22在用于根据目标生命场景需要使用的至少一个诊断服务，生成目标生命场景对应的所述诊断程序架构时，可具体用于：

响应于利用所述多个函数分别对所述至少一个诊断服务触发的服务逻辑配置操作，获得至少一个诊断功能项；

响应于利用所述至少一个诊断功能项针对车辆器件触发的配置诊断程序操作，获得目标生命场景对应的诊断程序序列；所述诊断程序序列中包含多个车辆器件诊断程序，一个车辆器件诊断程序用于诊断相对应的一个车辆器件；

响应于利用所述诊断程序序列针对车型触发的配置诊断程序操作，获取目标生命场景对应的诊断程序架构；所述诊断程序架构中包含多个车型诊断程序，一个车型诊断程序用于诊断相对应的一种车型车辆。

上述所述的车辆器件可以为但不限于控制器。控制器可以为单个的ECU（Electronic Control Unit，电子控制单元）；或者，也可以是由多个ECU集成而形成的域控制器，比如车载智能网关模块（BGM）、智能驾驶域控制器（ADC）等。

为便于理解，下面承接上述结合图4c所描述的示例以及结合图4b，举一示例详述一下获得研发生命场景对应的诊断程序架构的具体实现。

假设为研发场景选择的需要使用的至少一个诊断服务包括：诊断服务14、诊断服务17、诊断服务15等，以诊断服务14为例，用户可以从操作界面上显示的多个函数中选择函数1和函数4来为诊断服务14配置相应的服务逻辑，比如判断逻辑、循环逻辑等，配置完成后，便实现了将诊断服务14进行功能项程序模块化，从而得到诊断服务14对应的诊断功能项a14。以此类推，也可以得到至少一个诊断服务中除诊断服务14之外的其它诊断服务对应的诊断功能项。

进一步地，利用获得的至少一个诊断功能项，如图4b中示出的功能项21（如Configuration）、功能项22（如Immo）、功能项23（如Calibration）、功能项24（如Function）、功能项25（如Connect）、功能项26（如Security）、功能项27（如Config）、功能项28（如Calibar）等诊断功能项，可以配置研发场景下所用到的各控制器对应的控制器诊断程序，其中，在配置过程中，可对诊断功能项中函数的参数等进行设置。假设研发场景下所用到的控制器共有n个，具体地如包括ECU1、ECU2、ECU3、....、ECUn，以ECU1（如BGM）为例，配置ECU1对应的诊断程序需要使用到的诊断功能项包括：功能项25（如Connct）、功能项26（如Security）、功能项27（如Config）、功能项28（如Calibar），则用户可以调出预置的诊断程序标准模板，然后将上述功能项25（如Connect）、功能项26（如Security）、功能项27（如Config）及功能项28（如Calibar）这四个诊断功能项分别拖拽放入至诊断程序标准模块中适配的位置，以此便可得到ECU1对应的ECU1诊断程序，以此类推，也可以得到除ECU1之外的ECU2至ECUn各自对应的ECU诊断程序。上述针对ECU1至ECUn获得的n个ECU诊断程序均是可图视化的模块程序，用户可以对该n个ECU诊断程序，可采用时序图连线方式来配置该n个ECU诊断程序的排列顺序、或者也可以采用XML文件定义方式来编写定义该n个ECU诊断程序的排列顺序；按照该n个ECU诊断程序的排序顺序，对该n个ECU诊断程序进行序列化，便也就可得到研发场景对应的诊断程序序列。

再进一步地，可利用上述诊断程序序列包含的n个ECU诊断程序，配置研发场景下各车型对应的车型诊断程序，从而利用各车型对应的车型诊断程序来组成相应研发场景对应的诊断程序架构。具体地，假设研发场景下包括：P车型（如PMA 1车型）、D车型（如DMA 2车型），其中，P车型和D车型都使用有ECU1和ECU3等，此外，P车型还使用有ECUn等、D车型还使用有ECU2等，则：针对P车型，用户可从诊断程序序列中，选取出来ECU1诊断程序、ECU3诊断程序以及ECUn诊断程序等组成集合，构成P车型对应的车型诊断程序（如图4b中示出的P车型诊断程序）；以及从诊断程序序列中，选取出来ECU1诊断程序、ECU3诊断程序以及ECU2诊断程序等组合集合，构成D车型对应的车型诊断程序（如图4b中示出的D车型诊断程序）。由上可见，在分别构建P车型和D车型各自对应的车型诊断程序时，对诊断程序序列中的ECU1诊断程序和ECU3诊断程序可以进行复用，由此，针对不同车型间共同使用到的ECU，程序开发人员只需进行一次相应的ECU诊断程序开发即可，便能满足后续设计不同车型对应的车型诊断程序需求，这能有效解决开发程序成本；此外，若后续在其它生命场景中，比如制造场景，也能使用到此次针对研发场景开发的ECU诊断程序，则该针对研发场景开发的ECU诊断程序也能够在其它生命场景中使用，这使得开发出的ECU诊断程序能兼容多个生命场景。即在本实施例中，在不同生命场景下针对ECU开发设出的诊断程序序列，具备共用性。

之后，针对P车型和D车型获得的两个车型诊断程序，用户可以采用时序图连线方式来配置该该两个车型诊断程序的排列顺序、或者也可以采用XML文件定义方式来编写定义该两个车型诊断程序的排列顺序；按照该两个车型诊断程序的排序顺序，对该两个车型诊断程序进行序列化，便也就可采用积木形式搭建得到研发场景对应的诊断程序架构。

对针对不同生命场景开发设计的诊断程序架构，可按相应生命场景进行编译存储在本地，以备后续诊断设备请求获取时，将相应的诊断程序架构下发给适配的诊断设备。

这里需要补充说明的是，上述所述的编辑模块22可以为标准的开发工具，比如OTX编辑平台。其中，OTX（Open Test Sequence Exchange Format)，是一种开放式测试序列交换格式，在车辆诊断、自动化标定、ECU测试等领域有广泛应用，能开发诊断序列，方便诊断工程师使用。

综上可见，通过本实施例车辆诊断系统中提供的程序开发平台20，在应对车辆生命周期的多个生命场景时，能有效减少程序重复开发、资源浪费，以及降低程序开发周期和成本等。

进一步地，上述诊断设备40，主要功能是根据接收到的设备管理平台发送的功能配置信息，从数据管理平台、程序开发平台以及数据提供端获取相应的各类数据，以利用这些数据去诊断车辆。即，上述诊断设备40，具体用于：

根据接收到的所述功能配置信息，分别从所述程序开发平台中获取相应的诊断程序架构、从所述数据管理平台中获取相应的车辆订单数据、以及从所述数据提供端中获取相应的安全认证数据和整车软件；

响应于触发的诊断操作，利用获取到的所述诊断程序、所述车辆订单数据、所述整车软件以及所述安全认证数据，对与所述诊断设备通信连接的车辆进行诊断。

图5示出了诊断设备40的功能性原理示意图。如参见图5，诊断设备的功能具体实现原理可为如下：

1）通过相应的通信端口（如TCP端口，图中未示出）接收设备管理平台30下发的功能配置信息，其中，结合上文所描述的与功能配置信息相关的内容可获知，该功能配置信息中可包括：诊断设备标识、生命场景标识、诊断程序架构版本标识、整车软件版本标识、安全认证数据版本标识。之后，可根据该接收到的功能配置信息，分别向程序开发平台、数据提供端、数据管理平台发送相应的获取请求以获取相应的数据，并自动完成数据更新存储。

如以从程序开发平台中获取相应的诊断程序为例，诊断设备可根据其对应的功能配置信息中的生命场景标识和诊断程序架构版本标识，生成一获取请求并发送至程序开发平台；程序开发平台响应于该获取请求，便会按照获取请求中的生命场景标识和诊断程序架构版本标识，从本地存储的不同生命场景对应的诊断程序架构中执行查询，从将查询到的与获取请求匹配的诊断程序架构反馈至诊断设备；进一步地，诊断设备可将接收到诊断程序架构更新存储至自身内的诊断程序架构存储区，以备后续诊断车辆时调用。上述更新存储，可是诊断设备通过自身内置的更新模块来完成的。

再如，以从数据管理平台中获取相应的车辆订单数据为例，诊断设备可根据其对应的功能配置信息中的生命场景标识，生成一获取请求并发送至数据管理平台10。数据管理平台响应于该获取请求，根据获取请求中生命场景标识，可从自身包含的多个场景车辆订单数据库中确定出目标场景车辆订单数据库，从而将目标车辆订单数据库中存储的车辆订单数据反馈至诊断设备。进一步地，诊断设备可将接收到车辆订单数据更新存储至自身内的车辆订单数据存储区，以备后续诊断车辆时调用。

这里需要补充说明的是，考虑到通常目标车辆订单数据库中存储的车辆订单数据可能是众多的，有些车辆订单数据中包含的车辆数据与诊断设备诊断车辆所需使用的整车软件并不适配，而基于上文所描述的与车辆订单数据相关的内容可获知，车辆订单数据中是包含整车软件版本标识与车辆数据的，基于此，为保证车辆订单数据获取的精准性，具体地，诊断设备可根据其对应的功能配置信息中的生命场景标识和整车软件版本标识来生成一获取请求并发送至数据管理平台，从而数据管理平台根据获取请求中生命场景标识，从自身包含的多个场景车辆订单数据库中确定出目标场景车辆订单数据库后，可再根据获取请求中整车软件版本标识，从目标场景车辆订单数据库中执行查询操作，进而将查找到的符合要求的车辆订单数据返回至诊断设备；其中，含有获取请求中携带的整车软件版本标识的车辆订单数据，为符合要求的车辆订单数据。

有关诊断设备从整车软件中心、安全认证中心获取相应的整车软件和安全认证数据的具体实现，可参见针对诊断设备从程序开发平台获取相应的诊断程序所给出的示例。

2）诊断设备上可安装有用于诊断车辆的诊断应用，该诊断应用的图标可显示在诊断设备的UI界面上。用户通过诊断应用可触发诊断操作，诊断应用响应于该诊断操作，便会从诊断设备中调取并解析所存储的整车软件、车辆订单数据、诊断程序、安全认证数据；其中，诊断程序可以是诊断设备根据与其通信连接的车辆所属车型，比如P车型，从本地存储的诊断程序架构中获取到的关联有P车型标识的车型诊断程序，该车型诊断程序中包含有P车型车辆所使用到的所有车辆器件各自对应的车辆器件诊断程序。上述安全认证数据可以密钥证书等，利用安全认证数据可判断用户是否具有通过诊断设备诊断车辆的权限等，在认证通过后，将整车软件中的各软件、车辆订单数据中的各车辆数据刷写至车辆上相应的车辆器件（如控制器）中；刷写完成后，执行诊断程序以向车辆发送包含诊断参数、诊断指令等的诊断任务，从而对车辆进行诊断。以及，

诊断设备还会接收车辆返回的诊断测试结果，并将该诊断测试结果存储至本地的测试结果存储区，同时还会将诊断测试结果回传至数据管理平台，以使数据管理平台对诊断测试结果进行存储管理。有关数据管理平台如何对诊断测试结果进行存储管理，可参见上文详述数据管理平台时所描述的相关内容。

这里需要补充说明的是，诊断设备在与车辆进行数据交互时，还可利用安全认证数据对所交互的数据进行加解密操作等。此外，诊断设备在与车辆进行数据交互时，需经过自身内置的转换模块来实现。转换模块具体用于：将诊断设备需向车辆发送的数据转换成能被车辆识别的数据格式后，再转发至车辆；以及将车辆返回的测试结果数据转换成能被诊断设备识别的数据格式后，在发送至诊断设备中的测试结果存储区以进行存储。另外，诊断设备在对调取到的各类数据进行解析时，是利用自身内置的解析模块来实现的，解析模块可包含当不限于ODX解析器、OTX解析器等中的一种或组合。

上述所述的诊断设备可以为但不限于手持式平板、个人计算机（PersonalComputer，PC，如台式机、笔记本电脑、平板电脑、超级本等）、车载诊断设备（BGM Master）、智能手机等等，本实施例对诊断设备的类型不作具体限定。

综上，本实施例提供的车辆诊断系统包括设备管理平台、数据管理平台、程序开发平台、诊断设备；该车辆诊断系统向上能对接数据提供端，向下能承接车辆生命周期中不同生命场景的诊断业务，具有较高的灵活程度和自动化程度，通过该一套车辆诊断系统即可兼容车辆全生命周期的诊断业务，可有效减少设备投资、降低诊断成本等。

本申请还分别从上述所述的设备管理平台、数据管理平台、程序开发平台的角度，提供了几个车辆诊断方法实施例。具体地，

图6示出了本申请一实施例提供的车辆诊断方法的流程示意图，适用于图1中示出的设备管理平台30。如图6所示，本实施例提供的车辆诊断方法包括如下步骤：

101、为管理的至少一个诊断设备确定各自对应车辆的生命场景，其中，所述车辆生命周期包含多个生命场景；

102、记录程序开发平台中所存储的诊断程序架构更新迭代的程序架构版本信息；其中，程序开发平台中存储有所述多个生命场景中各生命场景对应的诊断程序架构；

103、根据每个诊断设备对应车辆的所述生命场景和所述程序架构版本信息，分别对每个诊断设备进行功能配置，生成包含每个诊断设备的功能配置信息的设备功能配置表；

104、将所述设备功能配置表中的功能配置信息发送至适配的诊断设备，以便所述诊断设备根据接收到的所述功能配置信息，获取相应的数据以备在诊断车辆时使用。

进一步地，本实施例提供的所述车辆诊断方法还包括：

记录数据提供端中所存储的整车软件更新迭代的软件版本信息、以及安全认证数据更新迭代的认证数据版本信息；其中，整车软件包含车辆的各车辆器件对应的软件，安全认证数据是供诊断设备诊断车辆时进行认证使用；

以及，在一种可实现方案中，上述103“根据每个诊断设备对应车辆的所述生命场景和所述程序架构版本信息，分别对每个诊断设备进行功能配置，生成包含每个诊断设备的功能配置信息的设备功能配置表”，可具体包括：

根据每个诊断设备对应的所述生命场景、所述程序架构版本信息、所述软件版本更信息以及所述认证数据版本信息，分别对每个诊断设备进行功能配置，以生成所述设备功能配置表。

有关设备管理平台以及上述各步骤的具体实现描述，可参见上文其他实施例中相关内容，此处就不再作赘述。

图7示出了本申请另一实施例提供的车辆诊断方法的流程示意图，适用于图1中示出的数据管理平台10。如图7所示，本实施例提供的车辆诊断方法包括如下步骤：

201、从数据提供端获取车辆在生命周期中不同生命场景下产生的车辆数据信息、以及整车软件的版本基线包；

202、基于所述版本基线包中包含的车辆器件标识与整车软件版本标识的对应关系、以及所述车辆数据信息中车辆数据携带的车辆器件标识，将所述版本基线包与所述车辆数据信息进行匹配，生成多个包含整车软件版本标识与车辆数据的车辆订单数据；

203、按照各车辆订单数据中车辆数据对应的所述生命场景，将各车辆订单数据进行存储，以备后续为诊断设备提供所需的车辆订单数据；

其中，所述诊断设备是根据从设备管理平台接收到的功能配置信息，向数据管理平台获取所需的车辆订单数据的；所述设备管理平台通过执行上述图6中示出的车辆诊断方法中的步骤向所述诊断设备发送适配的功能配置信息。

有关数据管理平台以及上述各步骤的具体实现描述，可参见上文其他实施例中相关内容，此处就不再作赘述。

图8示出了本申请又一实施例提供的车辆诊断方法的流程示意图，适用于图1中示出的程序开发平台20。如图8所示，本实施例提供的车辆诊断方法包括如下步骤：

301、接收数据提供端发送的诊断数据文件；其中，所述诊断数据文件是针对车辆生命周期开发诊断程序架构时所需依据的数据文件，所述诊断数据文件中包含诊断服务信息，所述生命周期包括多个生命场景；

302、对所述诊断数据文件进行解析，得到多个诊断服务；

303、从所述多个诊断服务中，确定各生命场景需要使用的至少一个诊断服务；

304、根据各生命场景需要使用的至少一个诊断服务，生成各生命场景对应的诊断程序架构，以备后续为诊断设备诊断车辆提供所需的诊断程序架构；

其中，所述诊断设备是根据从设备管理平台接收到的功能配置信息，向程序开发平台获取所需的诊断程序架构的；所述设备管理平台通过执行上述图6中示出的车辆诊断方法中的步骤向所述诊断设备发送适配的功能配置信息。

进一步地，目标生命场景为所述多个生命场景中的一个；以及相应地，

在一种可实现技术方案中，上述304中“根据目标生命场景需要使用的至少一个诊断服务，生成目标生命场景对应的诊断程序架构”，可具体包括：

3041、显示函数库中的多个函数；

3042、响应于利用所述多个函数分别对所述至少一个诊断服务触发的服务逻辑配置操作，获得至少一个诊断功能项；

3043、响应于利用所述至少一个诊断功能项针对车辆器件触发的配置诊断程序操作，获得所述目标场景对应的诊断程序序列；所述诊断程序序列中包含多个车辆器件诊断程序，一个车辆器件诊断程序用于诊断相对应的一个车辆器件；

3044、响应于利用所述诊断程序序列针对车型触发的配置诊断程序操作，获得目标生命场景对应的诊断程序架构；所述诊断程序架构中包含多个车型诊断程序，一个车型诊断程序用于诊断相对应的一种车型车辆。

有关程序开发平台以及上述各步骤的具体实现描述，可参见上文其他实施例中相关内容，此处就不再作赘述。

图9示出了本申请一实施例提供一个电子设备的结构示意图。如图9所示，所述电子设备包括：存储器91以及处理器92。其中，所述存储器91用于存储一条或多条计算机程序；所述处理器92，与所述存储器91耦合，用于执行所述存储器所存储的所述一条或多条计算机程序（如实现数据存储、处理等逻辑的计算机程序），以用于实现上述图6或图7或图8示出的车辆诊断方法实施例中的各步骤。

上述存储器91可以由任何类型的易失性或非易失性存储设备或者它们的组合实现，如静态随机存取存储器（SRAM），电可擦除可编程只读存储器（EEPROM），可擦除可编程只读存储器（EPROM），可编程只读存储器（PROM），只读存储器（ROM），磁存储器，快闪存储器，磁盘或光盘。

进一步，如图9所示，上述电子设备还可包括：通信组件93、电源组件94、音频组件95、显示器96（或称为显示模块）等其它组件。图9中仅示意性给出部分组件，并不意味着存储端只包括图9所示组件。

具体实施时，上述电子设备为图1中示出的设备管理平台、或者数据管理平台、或者程序开发平台。有关在电子设备为设备管理平台、或者数据管理平台、或者程序开发平台时的可包括的具体组件详述，可参见上文其他实施例中相关内容，此处不再作具体赘述。

相应地，本申请实施例还提供一种存储有计算机程序的计算机可读存储介质，所述计算机程序被计算机执行时能够实现上述各实施例提供的车辆诊断方法中步骤或对应功能。

本申请中的方法可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。图10示意性地示出了本申请提供的一计算机程序产品的框图。所述计算机程序产品包括一个或多个计算机程序/指令1001，在计算机上加载和执行所述计算机程序或指令1001时，可全部或部分地执行本申请所述的车辆控制方法中的流程或功能。所述计算机可以是通用计算机、专用计算机、计算机网络、网络设备、用户设备、核心网设备、OAM或者其它可编程装置。

所述计算机程序或指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一个计算机可读存储介质传输，例如，所述计算机程序或指令可以从一个网站站点、计算机、服务器或数据中心通过有线或无线方式向另一个网站站点、计算机、服务器或数据中心进行传输。所述计算机可读存储介质可以是计算机能够存取的任何可用介质或者是集成一个或多个可用介质的服务器、数据中心等数据存储设备。所述可用介质可以是磁性介质，例如，软盘、硬盘、磁带；也可以是光介质，例如，数字视频光盘；还可以是半导体介质，例如，固态硬盘。该计算机可读存储介质可以是易失性或非易失性存储介质，或可包括易失性和非易失性两种类型的存储介质。

最后应说明的是：以上实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的精神和范围。

Claims (10)

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

数据管理平台，其内存储有车辆在生命周期内的车辆订单数据；其中，所述生命周期包括多个生命场景，同一所述生命场景下的车辆订单数据存储在一起；

程序开发平台，用于开发并存储各所述生命场景对应的诊断程序架构；

设备管理平台，用于为管理的至少一个诊断设备确定各自对应的所述生命场景；记录所述诊断程序架构更新迭代的程序架构版本信息；根据每个所述诊断设备对应的所述生命场景和所述程序架构版本信息，分别对每个所述诊断设备进行功能配置，以生成包含每个所述诊断设备的功能配置信息的设备功能配置表；将所述设备功能配置表中的功能配置信息发送至适配的诊断设备；

至少一个诊断设备，所述诊断设备用于根据接收到的所述功能配置信息，分别从所述程序开发平台、所述数据管理平台中获取并存储相应的诊断程序架构、车辆订单数据，以备后续在对与所述诊断设备连接的车辆进行诊断时使用。

2.根据权利要求1所述的车辆诊断系统，其特征在于，所述车辆诊断系统通信连接有数据提供端；所述数据提供端能提供的数据包括：诊断不同生命场景下车辆所需使用的整车软件和安全认证数据；其中，所述整车软件中包含车辆的各车辆器件对应的软件；

以及，所述设备管理平台包括：

接收模块，用于接收所述程序开发平台针对诊断程序架构发送的版本更新信息，以及还用于接收所述数据提供端分别针对整车软件、安全认证数据发送的版本更新信息；并根据接收到的各版本更新信息，记录诊断程序架构更新迭代的程序架构版本信息、整车软件更新迭代的软件版本信息、安全认证数据更新迭代的认证数据版本信息；

场景配置模块，用于响应于对所述至少一个诊断设备触发的场景配置管理操作，为每个诊断设备配置对应的所述生命场景；

功能配置模块，用于根据每个诊断设备对应的所述生命场景、所述程序架构版本信息、所述软件版本信息及所述认证数据版本信息，分别对每个诊断设备进行功能配置，以生成包含每个诊断设备的功能配置信息的设备功能配置表；

发送模块，用于将所述设备功能配置表中的功能配置信息发送至适配的诊断设备。

3.根据权利要求2所述的车辆诊断系统，其特征在于，所述数据提供端能提供的数据还包括：车辆在生命周期中不同生命场景下产生的车辆数据信息；

以及，所述数据管理平台包括：

处理模块，用于从所述数据提供端获取所述车辆数据信息、以及整车软件的软件版本基线包；基于所述软件版本基线包中包含的车辆器件标识与整车软件版本标识的对应关系、以及所述车辆数据信息中车辆数据携带的车辆器件标识，将所述软件版本基线包与所述车辆数据信息进行匹配，生成多个包含整车软件版本标识与车辆数据的车辆订单数据；按照各车辆订单数据中车辆数据对应的所述生命场景，将各车辆订单数据存储至适配的场景车辆订单数据库中；

多个场景车辆订单数据库，一个所述场景车辆订单数据库用于存储一个所述生命场景下的车辆订单数据。

4.根据权利要求2所述的车辆诊断系统，其特征在于，所述数据提供端能提供的数据还包括：开发诊断程序架构所需依据的诊断数据文件，所述诊断数据文件中包含诊断服务信息；

以及，所述程序开发平台包括：

解析模块，用于对从所述数据提供端获取到的所述诊断数据文件进行解析，得到多个诊断服务；

编辑模块，用于从所述多个诊断服务中，确定各所述生命场景需要使用的至少一个诊断服务；根据各所述生命场景需要使用的至少一个诊断服务，生成各所述生命场景对应的所述诊断程序架构。

5.根据权利要求4所述的车辆诊断系统，其特征在于，所述程序开发平台还包括：操作界面，用于显示所述多个诊断服务、以及还用于显示函数库中的多个函数；以及，目标生命场景为所述多个生命场景中的一个，则

所述编辑模块，在用于从所述多个诊断服务中，确定目标生命场景需要使用的至少一个诊断服务时，具体用于：

响应于针对目标生命场景对所述多个诊断服务触发的选择操作，确定目标生命场景需要使用的至少一个诊断服务；

以及，在用于根据目标生命场景需要使用的至少一个诊断服务，生成目标生命场景对应的所述诊断程序架构时，具体用于：

响应于利用所述多个函数分别对所述至少一个诊断服务触发的服务逻辑配置操作，获得至少一个诊断功能项；

响应于利用所述至少一个诊断功能项针对车辆器件触发的配置诊断程序操作，获得目标生命场景对应的诊断程序序列；所述诊断程序序列中包含多个车辆器件诊断程序，一个车辆器件诊断程序用于诊断相对应的一个车辆器件；

响应于利用所述诊断程序序列针对车型触发的配置诊断程序操作，获得目标生命场景对应的诊断程序架构；所述诊断程序架构中包含多个车型诊断程序，一个车型诊断程序用于诊断相对应的一种车型车辆。

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

所述诊断设备，具体用于：根据接收到的所述功能配置信息，分别从所述程序开发平台中获取相应的诊断程序架构、从所述数据管理平台中获取相应的车辆订单数据、以及从所述数据提供端中获取相应的安全认证数据和整车软件；响应于触发的诊断操作，利用获取到的所述诊断程序架构、所述车辆订单数据、所述整车软件以及所述安全认证数据，对与所述诊断设备连接的车辆进行诊断；以及，

所述诊断设备，还用于接收所述车辆返回的诊断测试结果，并将所述诊断测试结果发送至所述数据管理平台。

7.一种车辆诊断方法，其特征在于，适用于设备管理平台，所述方法包括：

为管理的至少一个诊断设备确定各自对应车辆的生命场景，其中，所述车辆生命周期包含多个生命场景；

记录程序开发平台中所存储的诊断程序架构更新迭代的程序架构版本信息；其中，程序开发平台中存储有所述多个生命场景中各生命场景对应的诊断程序架构；

根据每个诊断设备对应车辆的所述生命场景和所述程序架构版本信息，分别对每个诊断设备进行功能配置，生成包含每个诊断设备的功能配置信息的设备功能配置表；

将所述设备功能配置表中的功能配置信息发送至适配的诊断设备，以便所述诊断设备根据接收到的所述功能配置信息，获取相应的数据以备在诊断车辆时使用。

8.一种车辆诊断方法，其特征在于，适用于具有数据管理平台，所述方法包括：

从数据提供端获取车辆在生命周期中不同生命场景下产生的车辆数据信息、以及整车软件的版本基线包；

基于所述版本基线包中包含的车辆器件标识与整车软件版本标识的对应关系、以及所述车辆数据信息中车辆数据携带的车辆器件标识，将所述版本基线包与所述车辆数据信息进行匹配，生成多个包含整车软件版本标识与车辆数据的车辆订单数据；

按照各车辆订单数据中车辆数据对应的所述生命场景，将各车辆订单数据进行存储，以备后续为诊断设备提供所需的车辆订单数据；

其中，所述诊断设备是根据从设备管理平台接收到的功能配置信息，向数据管理平台获取所需的车辆订单数据的；所述设备管理平台通过执行上述权利要求7所述的车辆诊断方法中的步骤向所述诊断设备发送适配的功能配置信息。

9.一种车辆诊断方法，其特征在于，适用于程序开发平台，所述方法包括：

接收数据提供端发送的诊断数据文件；其中，所述诊断数据文件是针对车辆生命周期开发诊断程序架构时所需依据的数据文件，所述诊断数据文件中包含诊断服务信息，所述生命周期包括多个生命场景；

对所述诊断数据文件进行解析，得到多个诊断服务；

从所述多个诊断服务中，确定各生命场景需要使用的至少一个诊断服务；

根据各生命场景需要使用的至少一个诊断服务，生成各生命场景对应的诊断程序架构，以备后续为诊断设备诊断车辆提供所需的诊断程序架构；

其中，所述诊断设备是根据从设备管理平台接收到的功能配置信息，向程序开发平台获取所需的诊断程序架构的；所述设备管理平台通过执行上述权利要求7中所述的车辆诊断方法中的步骤向所述诊断设备发送适配的功能配置信息。

10.一种电子设备，其特征在于，包括：存储器和处理器；其中，

所述存储器，用于存储计算机程序；

所述处理器，与所述存储器耦合，用于执行所述存储器中存储的所述计算机程序，以用于实现上述权利要求7所述的车辆诊断方法中的步骤、或者实现上述权利要求8所述的车辆诊断方法中的步骤、或者实现上述权利要求9所述的车辆诊断方法中的步骤；

其中，所述电子设备是上述权利要求1至6中任一项所述的车辆诊断系统中的设备管理平台、或数据管理平台、或程序开发平台。