一种车辆远程诊断方法、装置及系统

技术领域

本申请实施例涉及车辆智能控制技术领域，特别涉及一种车辆远程诊断方法、装置及系统。

背景技术

随着车载通信技术的发展，通过对车辆进行远程实时诊断的方式，能够极大地减少车辆返厂维修的次数和时间，便于用户和原始设备制造商(Original EquipmentManufacturer，OEM)及时采取有效的安全保护措施，同时为车辆的返厂维修提供有效的车辆故障数据，已逐渐成为车辆故障诊断的主要方式之一。目前，车载诊断标准协议已逐渐完善并适配于各种远程诊断装置，例如，基于网际协议进行诊断通信(Diagnosticcommunicate over Internet Protocol，DoIP)标准协议、基于控制器局域网络(controller area network，CAN)进行诊断通信(Diagnose over CAN，DoCAN)标准协议。

然而，由于车载诊断标准协议主要是在通用的网络协议(例如IP协议、CAN协议)之上定义的专用于统一诊断服务(Unified Diagnostic Services，UDS)诊断的协议，由于这些通用的网络协议本身的通信机制限制，在将这些车载诊断标准协议应用于移动互联网中时，在云端服务器和车辆之间存在网络延迟、网络阻塞等不确定性的情况下，云端服务器无法准确匹配诊断请求报文与来自车辆的诊断响应报文，由此，将导致云端服务器解析结果不准确的问题。

发明内容

本申请实施例提供一种车辆远程诊断方法、装置及系统，有助于在车辆远程诊断场景中，通过确定诊断请求报文与诊断响应报文的匹配关系，提高车辆远程诊断分析的准确性。

第一方面，本申请实施例提供了一种车辆远程诊断方法，该方法可应用于车辆远程诊断装置，该车辆远程诊断装置可以部署在车辆端，可以是应用于整车车辆，或车辆中芯片或部件，还可以是软件模块，可以部署在车辆上的其它智能设备，例如手机、平板电脑等。本申请实施例中，为了便于区分，在车辆侧，可以将该车辆远程诊断装置称为车端诊断代理装置。示例的，该车端诊断代理装置可以集成在车辆中的车载盒子(telematics BOX，T-Box)，或域控制器(domian controller，DC)，或多域控制器(multi-domian controller，MDC)，或车载单元(on board unit，OBU)或车载网关等，本申请实施例对该车端诊断代理装置的部署方式或产品形态不做限定。

该方法包括：接收来自远程诊断装置的第一诊断请求报文，所述第一诊断请求报文用于对所述车辆进行远程诊断，所述第一诊断请求报文中包含所述第一诊断请求报文的标识；根据所述第一诊断请求报文的标识和所述车辆的诊断数据，确定第一诊断响应报文，所述诊断数据是根据所述第一诊断请求报文获取的；向所述远程诊断装置发送所述第一诊断响应报文。

通过上述方法，通过在相关车载诊断标准协议中引入会话机制，在第一诊断请求报文中增加该报文的标识，并基于同一标识对该第一诊断请求报文进行应答，从而基于同一标识关联第一诊断请求报文和相应的诊断响应报文，有助于在车辆远程诊断场景中，通过确定诊断请求报文与诊断响应报文的匹配关系，提升远程诊断分析的准确性。

结合第一方面，在一种可能的实现中，所述第一诊断请求报文中还包含负载和第一指示信息，所述第一指示信息用于指示所述第一诊断请求报文中包含与所述负载关联的数据头。

通过上述方法，在第一诊断请求报文中增加用于指示与报文负载关联的数据头的第一指示信息，以使得车辆侧的诊断代理装置可以对该数据头进行解析，从而获得关于报文负载的相关解释说明，有助于在车辆远程诊断场景中，通过确定诊断请求报文与诊断响应报文的匹配关系，提升远程诊断分析的准确性。

结合第一方面，在一种可能的实现中，所述第一诊断请求报文中还可以包含第二指示信息，所述第二指示信息用于指示所述第一诊断请求报文属于一组诊断请求报文序列。

通过上述方法，通过在相关车载诊断标准协议中引入长诊断指令序列机制，并在第一诊断请求报文中增加用于指示该报文是否属于一组诊断请求报文序列的第二指示信息，以使得车辆侧的诊断代理装置可以在对该第二指示信息进行解析，从而获得关于该组诊断请求报文序列的相关解释说明，有助于在车辆远程诊断场景中，通过确定诊断请求报文与诊断响应报文的匹配关系，提升远程诊断分析的准确性。

结合第一方面，在一种可能的实现中，所述第一诊断请求报文中还可以包含第三指示信息，所述第三指示信息用于指示以下属性信息：所述一组诊断请求报文序列的标识、所述一组诊断请求报文序列中的诊断请求报文的数量和所述第一诊断请求报文在所述一组诊断请求报文序列中的序号。

通过上述方法，通过在第一诊断请求报文中增加第三指示信息来指示该第一诊断请求报文与所属的诊断请求报文序列的关联关系，有助于在车辆远程诊断场景中，通过确定诊断请求报文与诊断响应报文的匹配关系，提升远程诊断分析的准确性。

结合第一方面，在一种可能的实现中，所述第一诊断请求报文属于一组诊断请求报文序列，所述方法还包括：根据所述一组诊断请求报文序列的标识、以及所述第一诊断请求报文在所述一组诊断请求报文序列中的序号，指示所述远程诊断装置发送所述第一诊断请求报文。

通过上述方法，远程诊断装置和车辆侧的诊断代理装置双方之间可以多帧协商请求报文和响应报文的发送、重发、补发机制等，减少个别报文的丢包情况，有助于在车辆远程诊断场景中，通过确定诊断请求报文与诊断响应报文的匹配关系，提升远程诊断分析的准确性。

结合第一方面，在一种可能的实现中，所述第一诊断请求报文属于一组诊断请求报文序列，所述方法还包括：对属于同一组诊断请求报文序列的至少两个诊断请求报文进行组包处理，所述至少两个诊断请求报文包括所述第一诊断请求报文。

通过上述方法，在引入长诊断指令序列机制的情况下，车辆侧的诊断代理装置可以等待接收到属于同一组诊断请求报文序列的至少两个诊断请求报文后，对该至少两个诊断请求报文进行组包处理和应答，减少因网络延迟、网络阻塞等不确定性而导致序列中报文乱序引起的解析不准确的问题，有助于在车辆远程诊断场景中，通过确定诊断请求报文与诊断响应报文的匹配关系，提升远程诊断分析的准确性。

结合第一方面，在一种可能的实现中，根据所述第一诊断请求报文的标识和所述车辆的诊断数据，确定第一诊断响应报文，包括：在所述诊断数据满足第一分包条件时，根据所述第一诊断请求报文的标识和所述诊断数据，确定至少两个诊断响应报文，其中，所述至少两个诊断响应报文包括所述第一诊断响应报文，所述至少两个诊断响应报文属于同一组诊断响应报文序列，所述至少两个诊断响应报文中均包含所述第一诊断请求报文的标识。

通过上述方法，通过在相关车载诊断标准协议中引入分包机制，使得车辆侧的诊断代理装置可以对车辆的诊断数据进行分包多次发送，减少因数据包容量限制导致的部分报文丢弃而引起的解析不准确的问题，有助于在车辆远程诊断场景中，通过确定诊断请求报文与诊断响应报文的匹配关系，提升远程诊断分析的准确性。

第二方面，本申请实施提供了一种车辆远程诊断方法，该方法可应用于远程诊断装置，该远程诊断装置可以是独立设备或设备中的芯片或部件，可以是应用程序、或软件模块，可通过安装和运行在手机、平板电脑等智能设备中，可以部署在云端服务器中，本申请实施例对该远程诊断装置的部署方式或产品形态不做限定。

该方法包括：确定第一诊断请求报文，所述第一诊断请求报文用于对所述车辆进行远程诊断，所述第一诊断请求报文中包含所述第一诊断请求报文的标识；向所述车辆发送第一诊断请求报文；接收所述车辆的第一诊断响应报文，所述第一诊断响应报文中包含所述第一诊断请求报文的标识、以及所述车辆的诊断数据，所述诊断数据是根据所述第一诊断请求报文获取的。

结合第二方面，在一种可能的实现中，所述第一诊断请求报文中还包含负载和第一指示信息，所述第一指示信息用于指示所述第一诊断请求报文中包含与所述负载关联的数据头。

结合第二方面，在一种可能的实现中，所述第一诊断请求报文中还包含第二指示信息，所述第二指示信息用于指示所述第一诊断请求报文属于一组诊断请求报文序列。

结合第二方面，在一种可能的实现中，所述第一诊断请求报文中还包含第三指示信息，所述第三指示信息用于指示以下属性信息：所述一组诊断请求报文序列的标识、所述一组诊断请求报文序列中的诊断请求报文的数量和所述第一诊断请求报文在所述一组诊断请求报文序列中的序号。

结合第二方面，在一种可能的实现中，所述确定第一诊断请求报文，包括：在所述诊断任务满足第二分包条件时，确定至少两个诊断请求报文，所述至少两个诊断请求报文包括所述第一诊断请求报文，所述至少两个诊断请求报文属于同一组诊断请求报文序列。

结合第二方面，在一种可能的实现中，所述向所述车辆发送第一诊断请求报文时，包括：向所述车辆发送所述第一诊断请求报文所属的一组诊断请求报文序列；或者，根据所述车辆指示的一组诊断请求报文序列的标识、以及所述第一诊断请求报文在所述一组诊断请求报文序列中的序号，向所述车辆发送所述第一诊断请求报文。

结合第二方面，在一种可能的实现中，所述第一诊断响应报文属于一组诊断响应报文序列，所述方法还包括：对属于同一组诊断响应报文序列的至少两个诊断响应报文进行组包处理，所述至少两个诊断响应报文包括所述第一诊断响应报文。

第三方面，本申请实施例提供了一种车辆远程诊断装置，包括：接收单元，用于接收来自远程诊断装置的第一诊断请求报文，所述第一诊断请求报文用于对所述车辆进行远程诊断，所述第一诊断请求报文中包含所述第一诊断请求报文的标识；处理单元，用于根据所述第一诊断请求报文的标识和所述车辆的诊断数据，确定第一诊断响应报文，所述诊断数据是根据所述第一诊断请求报文获取的；发送单元，用于向所述远程诊断装置发送所述第一诊断响应报文。

结合第三方面，在一种可能的实现中，所述第一诊断请求报文中还包含负载和第一指示信息，所述第一指示信息用于指示所述第一诊断请求报文中包含与所述负载关联的数据头。

结合第三方面，在一种可能的实现中，所述第一诊断请求报文中还包含第二指示信息，所述第二指示信息用于指示所述第一诊断请求报文属于一组诊断请求报文序列。

结合第三方面，在一种可能的实现中，所述第一诊断请求报文中还包含第三指示信息，所述第三指示信息用于指示以下属性信息：所述一组诊断请求报文序列的标识、所述一组诊断请求报文序列中的诊断请求报文的数量和所述第一诊断请求报文在所述一组诊断请求报文序列中的序号。

结合第三方面，在一种可能的实现中，所述第一诊断请求报文属于一组诊断请求报文序列，所述装置还包括：指示单元，用于根据所述一组诊断请求报文序列的标识、以及所述第一诊断请求报文在所述一组诊断请求报文序列中的序号，指示所述远程诊断装置发送所述第一诊断请求报文。

结合第三方面，在一种可能的实现中，所述第一诊断请求报文属于一组诊断请求报文序列，所述装置还包括：组包单元，用于对属于同一组诊断请求报文序列的至少两个诊断请求报文进行组包处理，所述至少两个诊断请求报文包括所述第一诊断请求报文。

结合第三方面，在一种可能的实现中，所述处理单元用于：在所述诊断数据满足第一分包条件时，根据所述第一诊断请求报文的标识和所述诊断数据，确定至少两个诊断响应报文，其中，所述至少两个诊断响应报文包括所述第一诊断响应报文，所述至少两个诊断响应报文属于同一组诊断响应报文序列，所述至少两个诊断响应报文中均包含所述第一诊断请求报文的标识。

第四方面，本申请实施例提供了一种车辆远程诊断装置，包括：处理单元，用于确定第一诊断请求报文，所述第一诊断请求报文用于对所述车辆进行远程诊断，所述第一诊断请求报文中包含所述第一诊断请求报文的标识；发送单元，用于向所述车辆发送第一诊断请求报文；接收单元，用于接收所述车辆的第一诊断响应报文，所述第一诊断响应报文中包含所述第一诊断请求报文的标识、以及所述车辆的诊断数据，所述诊断数据是根据所述第一诊断请求报文获取的。

结合第四方面，在一种可能的实现中，所述第一诊断请求报文中还包含负载和第一指示信息，所述第一指示信息用于指示所述第一诊断请求报文中包含与所述负载关联的数据头。

结合第四方面，在一种可能的实现中，所述第一诊断请求报文中还包含第二指示信息，所述第二指示信息用于指示所述第一诊断请求报文属于一组诊断请求报文序列。

结合第四方面，在一种可能的实现中，所述第一诊断请求报文中还包含第三指示信息，所述第三指示信息用于指示以下属性信息：所述一组诊断请求报文序列的标识、所述一组诊断请求报文序列中的诊断请求报文的数量和所述第一诊断请求报文在所述一组诊断请求报文序列中的序号。

结合第四方面，在一种可能的实现中，所述处理单元用于：在所述诊断任务满足第二分包条件时，确定至少两个诊断请求报文，所述至少两个诊断请求报文包括所述第一诊断请求报文，所述至少两个诊断请求报文属于同一组诊断请求报文序列。

结合第四方面，在一种可能的实现中，所述发送单元用于：向所述车辆发送所述第一诊断请求报文所属的一组诊断请求报文序列；或者，根据所述车辆指示的一组诊断请求报文序列的标识、以及所述第一诊断请求报文在所述一组诊断请求报文序列中的序号，向所述车辆发送所述第一诊断请求报文。

结合第四方面，在一种可能的实现中，所述第一诊断响应报文属于一组诊断响应报文序列，所述装置还包括：组包单元，用于对属于同一组诊断响应报文序列的至少两个诊断响应报文进行组包处理，所述至少两个诊断响应报文包括所述第一诊断响应报文。

第五方面，本申请实施例提供了一种车辆远程诊断装置，包括：处理器和存储器；所述存储器用于存储程序；所述处理器用于执行所述存储器所存储的程序，以使所述装置实现如上第一方面或第一方面任一可能的设计所述的方法。

第六方面，本申请实施例提供了一种车辆远程诊断装置，包括：处理器和存储器；所述存储器用于存储程序；所述处理器用于执行所述存储器所存储的程序，以使所述装置实现如上第二方面或第二方面任一可能的设计所述的方法。

第七方面，本申请实施例提供了一种车辆远程诊断系统，包括：如上第三方面或第三方面任一可能的设计所述的车辆远程诊断装置，和，如上第四方面或第四方面任一可能的设计所述的车辆远程诊断装置。

第八方面，本申请实施例提供了一种计算机可读存储介质，所述计算机可读存储介质存储有程序代码，当所述程序代码在所述计算机上运行时，使得计算机执行上述第一方面以及第一方面可能的设计所述的方法，或者，当所述程序代码在计算机上运行时，使得计算机执行上述第二方面以及第二方面可能的设计所述的方法。

第九方面，本申请实施例提供了一种计算机程序产品，当所述计算机程序产品在计算机上运行时，使得所述计算机执行上述第一方面以及第一方面可能的设计所述的方法，或执行上述第二方面以及第二方面可能的设计所述的方法。

第十方面，本申请实施例提供了一种芯片系统，该芯片系统包括处理器，用于调用存储器中存储的计算机程序或计算机指令，以使得该处理器执行上述第一方面以及第一方面可能的设计所述的方法，或执行上述第二方面以及第二方面可能的设计所述的方法。

结合第十方面，在一种可能的实现方式中，该处理器通过接口与存储器耦合。

结合第十方面，在一种可能的实现方式中，该芯片系统还包括存储器，该存储器中存储有计算机程序或计算机指令。

第十一方面，本申请实施例提供了一种处理器，该处理器用于调用存储器中存储的计算机程序或计算机指令，以使得该处理器执行上述第一方面以及第一方面可能的设计所述的方法，或执行上述第二方面以及第二方面可能的设计所述的方法。

本申请实施例在上述各方面提供的实现的基础上，还可以进行进一步组合以提供更多实现。

上述第三方面至第十一方面中任一方面中的任一可能设计可以达到的技术效果，可以相应参照上述第一方面或第二方面中任一方面中的任一可能设计可以达到的技术效果描述，重复之处不予论述。

附图说明

图1示出了本申请实施例适用的应用场景的示意图；

图2示出了本申请实施例适用的系统架构图；

图3示出了一种报文结构的示意图；

图4示出了第一报文格式的示意图；

图5示出了第二报文格式的示意图；

图6示出了第三报文格式的示意图；

图7示出了一种报文结构的示意图；

图8示出了本申请实施例的车辆远程诊断方法的流程示意图；

图9示出了本申请实施例的车辆远程诊断装置的示意图；

图10示出了本申请实施例的车辆远程诊断装置的示意图；

图11示出了本申请实施例的车辆远程诊断装置的示意图。

具体实施方式

随着科技的发展，车辆行业的各种业务也日益成熟，车辆的电气系统也日益复杂。在车辆的系统中，通常配置有许多称为电子控制单元(electronic control unit，ECU)的部件，是车辆专用微机控制器。多个ECU之间基于汽车总线(automotive bus)(一种多路复用通信网络技术)进行信息传递，形成车辆内部的局域网络。目前的汽车总线主要包括：控制器局域网络(controller area network，CAN)总线、局域互联网(Local InterconnectNetwork，LIN)总线、高速容错网络协议(FlexRay)总线、用于汽车多媒体和导航的媒体导向系统传输(Media Oriented Systems Transport，MOST)总线以及与计算机网络兼容的蓝牙、无线局域网等。

车载标准诊断协议中，远程诊断装置在实现对车辆的远程诊断时，一般是通过与车辆内的多个ECU进行通信，基于汽车总线，采用相应的远程诊断方式对车载网络中底层的车用设备或车用仪表等进行故障诊断，例如：读故障码、清除故障码、设码、读数据流、读取车辆信息、例程控制、ECU复位、动作测试、程序刷写等。目前，车载诊断相关标准协议已逐渐完善并适配于各种远程诊断装置，不仅适配逐步完善的车辆功能和复杂的ECU，而且适配车辆不断增加的各种ECU功能的扩展和升级。

在移动互联网络场景中，远程诊断装置可以是安装和运行在移动设备的云诊断应用程序(简称为云诊断应用)，该云诊断应用可以使用基于网络协议进行诊断通信(Diagnostic communicate over Internet Protocol，DoIP)标准或基于控制器局域网络(controller area network，CAN)进行诊断通信(Diagnose over CAN，DoCAN)标准协议等的相关车载诊断标准协议，通过云端服务器和车载设备，在基于上述至少一种汽车总线的不同设备之间实现协议转换和数据传输，以完成对车辆的远程实时诊断。

然而，由于上述相关车载诊断标准协议主要是在通用的网络协议(例如IP协议、CAN协议)之上定义的专用于统一诊断服务(Unified Diagnostic Services，UDS)诊断的协议，由于这些通用的网络协议本身的通信机制限制，在该场景中面临云端服务器和车载设备之间存在网络延迟、网络阻塞等不确定性的情况，云端服务器无法准确匹配诊断请求报文与来自车端通信设备的诊断响应报文，由此，将导致云端服务器解析结果不准确的问题。

本申请实施例提供了一种车辆远程诊断方法、装置及系统，通过在相关车载诊断标准协议中引入会话(session)机制，有助于在车辆远程诊断场景中，较为准确地确定诊断请求报文与诊断响应报文的匹配关系，提高车辆远程诊断和分析的准确性。其中，方法和装置是基于同一技术构思的，由于方法及装置解决问题的原理相似，因此装置与方法的实施可以相互参见，重复之处不再赘述。

需要说明的是，本申请实施例中的车辆远程诊断方案可以应用于车联网，如车-万物(vehicle to everything，V2X)、车间通信长期演进技术(long term evolution-vehicle，LTE-V)、车辆-车辆(vehicle to vehicle，V2V)等。例如可以应用于具有驾驶移动功能的车辆，或者车辆中具有驾驶移动功能的其它装置。该其它装置包括但不限于：车载终端、车载控制器、车载模块、车载模组、车载部件、车载芯片、车载单元、车载雷达或车载摄像头等其他传感器，车辆可通过该车载终端、车载控制器、车载模块、车载模组、车载部件、车载芯片、车载单元、车载雷达或车载摄像头，实施本申请实施例提供的车辆远程诊断方法。当然，本申请实施例中的控制方案还可以用于除了车辆之外的其它具有移动控制功能的智能终端，或设置在除了车辆之外的其它具有移动控制功能的智能终端中，或设置于该智能终端的部件中。该智能终端可以为智能运输设备、智能家居设备、机器人等。例如包括但不限于智能终端或智能终端内的控制器、芯片、雷达或摄像头等其它传感器、以及其它部件等。

需要说明的是，本申请实施例中“至少一个”是指一个或者多个，“多个”是指两个或两个以上。“和/或”，描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B的情况，其中A，B可以是单数或者复数。字符“/”一般表示前后关联对象是一种“或”的关系。“以下至少一项(个)”或其类似表达，是指的这些项中的任意组合，包括单项(个)或复数项(个)的任意组合。例如，a,b,或c中的至少一项(个)，可以表示：a,b,c,a和b,a和c,b和c,或a和b和c，其中a,b,c可以是单个，也可以是多个。

以及，除非有特别说明，本申请实施例提及“第一”、“第二”等序数词是用于对多个对象进行区分，不用于限定多个对象的优先级或者重要程度。例如，第一指示信息、第二指示信息，只是为了区分不同的指示信息，而不是表示这两个指示信息的优先级或者重要程度等的不同。

为便于理解，下面结合附图及实施例进行介绍。

图1示出了本申请实施例适用的应用场景的示意图。在该应用场景中，可以包括车辆100和云端服务器200，车辆100和云端服务器200可以通过网络通信。

车辆100的部分或所有功能受计算平台150控制。计算平台150可包括至少一个处理器151，处理器151可以执行存储在例如存储器152这样的非暂态计算机可读介质中的指令153。在一些实施例中，计算平台150还可以是采用分布式方式控制车辆100的个体组件或子系统的多个计算设备。处理器151可以是任何常规的处理器，诸如中央处理单元(centralprocessing unit，CPU)。替选地，处理器151还可以包括诸如图像处理器(graphic processunit，GPU)，现场可编程门阵列(field programmable gate array，FPGA)、片上系统(system on chip，SOC)、专用集成芯片(application specific integrated circuit，ASIC)或它们的组合。

除了指令153以外，存储器152还可存储数据，例如道路地图、路线信息，车辆的位置、方向、速度以及其它这样的车辆数据，以及其他信息。这种信息可在车辆100在自主、半自主和/或手动模式中操作期间被车辆100和计算平台150使用。应理解，图1中车辆的结构不应理解为对本申请实施例的限制。

可选地，上述车辆100可以为轿车、卡车、摩托车、公共汽车、船、飞机、直升飞机、割草机、娱乐车、游乐场车辆、施工设备、电车、高尔夫球车、火车等，本申请实施例不做特别的限定。

另外，如图1所示的应用场景中还可以包括云端服务器200。本申请实施例中，远程诊断装置可以部署在该云端服务器200中，该远程诊断装置可以向车辆发送远程的诊断请求报文、并接收来自车辆的诊断响应报文，通过对诊断请求报文与相应的诊断响应报文的匹配与解析，实现对车辆的远程诊断，提高车辆远程诊断分析的准确性。车辆100还可以包括诊断代理装置154，该诊断代理装置154可以对来自远程诊断装置的诊断请求报文进行处理、并向该远程诊断装置反馈诊断响应报文，以便远程诊断装置完成对车辆的远程实时诊断。需要说明的是，图1中示出的装置代理装置154仅为说明车辆侧的计算平台150可实现诊断代理功能，该诊断代理功能可以由独立装置实现，也可以由处理器151实现，本申请实施例对此不做限定。

一个实施例中，该云端服务器还可以通过虚拟机来实现。

图2示出了本申请实施例适用的系统架构图。参阅图2所示，该系统可以包括远程诊断装置210、以及车辆100侧的诊断代理装置154、M个诊断节点(node)120、以及任一诊断节点120关联的n个ECU 130。M、n为大于等于1的整数。

其中，远程诊断装置210可以是应用程序、或软件模块、独立设备或设备中的芯片或部件，可以部署在图1所示的云端服务器200中，可通过安装和运行在手机、平板电脑等智能设备中的应用程序进行控制。诊断代理装置154可以是车辆100上的车载T-Box，也可以是车辆上的车载网关或其它车载设备，本申请实施例对该远程诊断装置210或诊断代理装置220的部署方式或产品形态不做限定。

本申请实施例中，诊断代理装置可以称为车辆侧的车载诊断边缘节点，该诊断代理装置可以根据来自远程诊断装置的激活请求报文激活相应的诊断节点(node)，并由已激活的各个诊断节点根据来自远程诊断装置的诊断请求报文从关联的ECU获得车辆的诊断数据。其中，M个诊断节点120可以包括但不限于：车载娱乐单元(Integrated CockpitController，ICC)、自动驾驶单元(例如高级驾驶辅助系统(Advanced Driving AssistanceSystem，ADAS))、整车控制单元(Vehicle control unit，VCU)、车身控制单元(bodycontrol module，BCM)等，不同诊断节点120的诊断类型可以不同，例如ICC、ADAS、VCU可通过DoIP协议实现诊断，BCM可通过DoCAN协议实现诊断。

远程诊断装置210在确定需要对车辆100进行远程诊断时，可以确定诊断请求报文并向所述车辆100发送该诊断请求报文，以向车辆100发起远程诊断流程。相应地，车辆100侧的诊断代理装置154可以接收来自所述远程诊断装置210的诊断请求报文，并根据所述诊断请求报文和相应的诊断节点120，来对车辆100的各个ECU 130进行远程诊断，得到车辆的诊断数据。进一步地，车辆100侧的诊断代理装置154可以根据车辆的诊断数据，向所述远程诊断装置210反馈诊断响应报文。相应地，远程诊断装置210可以对来自车辆的所述诊断响应报文进行解析，得到车辆的远程诊断结果。

本申请实施例中，为了较为准确地确定诊断请求报文与诊断响应报文的匹配关系，提高车辆远程诊断分析的准确性，一种可能的实现方式是，在相关车载诊断标准协议中引入会话(session)机制，并据此制定新的报文格式(为便于区分，可表示为第一报文格式)，使得远程诊断装置210和车辆100侧的诊断代理装置154之间可以基于所述第一报文格式确定待向对端装置传输的相应报文，从而减少由于网络延迟、网络阻塞等不确定性带来的解析结果不准确的问题。

实施时，远程诊断装置210(即诊断请求的发起方，或称为诊断请求报文发送方、诊断响应报文接收方)可以在基于第一报文格式确定的诊断请求报文中增加该诊断请求报文的标识，该标识可以用于唯一标识所述诊断请求报文。相应地，诊断代理装置154(即诊断请求的响应方，或称为诊断请求报文接收方、诊断响应报文发送方)在根据所述诊断请求报文向所述发送端反馈诊断响应报文时，可以在该诊断响应报文中增加所述诊断请求报文的标识。由此，诊断请求的发起方可以根据同一标识，确定诊断请求报文和诊断响应报文之间的匹配关系，在诊断请求的响应方反馈的多条诊断响应报文中，较为准确地确定出某条诊断请求报文的应答，保障车辆的远程诊断解析结果的准确性。

需要说明的是，本申请实施例中，该诊断请求报文的标识具体可以是序列号(sequence Identity document)、编号等，本申请实施例对此标识的具体实现方式不做限定。该标识可以根据经验或业务需求，承载在诊断请求报文或诊断响应报文的相应字段中，下文中将结合具体报文结构示例对此进行说明，在此暂不赘述。

在一些情形下，诊断请求的发起方可能需要基于一组连续的诊断指令事务，向待诊断的车辆发起一组诊断请求报文集合(包含多个诊断请求报文)，该集合中的多个诊断请求报文需要按照报文顺序进行处理和应答，在云端服务器和车辆之间存在网络延迟、网络阻塞等不确定性的情况下，该集合中的多个诊断请求报文的顺序可能会出现乱序的问题，从而导致对这多个诊断请求报文的处理和应答混乱，云端服务器无法准确匹配诊断请求报文与来自车辆的诊断响应报文，导致解析结果不准确。

本申请实施例中，通过确定诊断请求报文与诊断响应报文的匹配关系，提高车辆远程诊断分析的准确性，一种可能的实现方式是，在相关车载诊断标准协议中引入长诊断指令序列机制，并据此制定新的报文格式(为便于区分，可表示为第二报文格式)，使得远程诊断装置210和车辆100侧的诊断代理装置154之间可以基于第二报文格式确定待向对端装置传输的相应报文序列(包含多个报文)，从而基于对属于同一组诊断请求报文序列的若干个诊断请求报文和诊断响应报文的解析，减少由于网络延迟、网络阻塞等不确定性带来的解析结果不准确的问题。

可选的，远程诊断装置210可以根据诊断任务，决策是否需要向待诊断的车辆发送一组诊断请求报文序列。在不需要的情况下，该远程诊断装置210可以向所述车辆发送单个诊断请求报文，该诊断请求报文中不包含与报文负载关联的报文头。在需要的情况下，该远程诊断装置210可以向所述车辆发送一组诊断请求报文序列，同时，基于所述第二报文格式在该组诊断请求报文序列的每个诊断请求报文中增加与报文负载关联的报文头，该报文头中包含的相关信息可用于对诊断请求报文的报文负载的相关属性进行解释说明，由此，以便车辆侧的诊断代理装置154可以基于该报文头中的相关信息，对接收到的诊断请求报文进行解析并做出应答。

在一个示例中，远程诊断装置210可以在该诊断请求报文中包含与报文负载关联的报文头时，在该诊断请求报文中增加该第一指示信息，该第一指示信息可用于指示所述诊断请求报文中包含与报文负载关联的报文头；在该诊断请求报文中不包含报文负载关联的报文头的情况下，不在该诊断请求报文中增加该第一指示信息。或者，在另一个示例中，在诊断请求报文中增加第一指示信息，该第一指示信息可以用于指示该诊断请求报文中是否包含与报文负载关联的报文头。其中，该第一指示信息可以采用不同的字节值，以指示该诊断请求报文中是否包含与负载关联的报文头。例如，该第一指示信息可以取值为0x00，指示该诊断请求报文中不包含与报文负载关联的报文头；该第一指示信息可以取值为0x01，指示该诊断请求报文中包含与报文负载关联的报文头。相应地，诊断代理装置154可以在诊断请求报文中不包含第一指示信息、或第一指示信息的取值为0x00的情况下，基于相关车载诊断标准协议的报文格式，对该诊断请求报文中的报文负载进行解析并做出应答；在诊断请求报文中包含第一指示信息、或第一指示信息的取值为0x01的情况下，基于所述第二报文格式，对与报文负载关联的报文头以及报文负载进行解析并做出应答。

在另一个示例中，诊断请求报文中可以包括第二指示信息，该第二指示信息可用于指示该诊断请求报文是否属于一组诊断请求报文序列。示例的，该第二指示信息可以包含在与诊断请求报文的报文负载关联的报文头中。其中，该第二指示信息也可以采用不同的字节值，以指示该诊断请求报文是否属于一组诊断请求报文序列。例如，该第二指示信息可以取值为0x00，指示该诊断请求报文由单条诊断指令事务触发，不属于诊断请求报文序列；该第二指示信息可以取值为0x01，指示该诊断请求报文由一组连续的诊断指令事务触发，属于一组诊断请求报文序列。相应地，诊断代理装置154可以在第二指示信息的取值为0x00的情况下，基于相关车载诊断标准协议的报文格式，对该诊断请求报文中的报文负载进行解析并做出应答；在第二指示信息的取值为0x01的情况下，基于所述第二报文格式，对属于同一组诊断请求报文序列的至少两个诊断请求报文进行组包处理和应答。

在另一个示例中，诊断请求报文中可以包含第三指示信息，该第三指示信息用于指示以下属性信息：一组诊断请求报文序列的标识、一组诊断请求报文序列中的诊断请求报文的数量和当前的诊断请求报文在所述一组诊断请求报文序列中的序号。示例的，该第三指示信息可以包含在与诊断请求报文的报文负载关联的报文头中。相应地，诊断代理装置154可以根据所述第三指示信息，具体执行对属于同一组诊断请求报文序列的至少两个诊断请求报文的组包处理和应答的操作。

需要说明的是，本申请实施例中，在基于相关车载诊断标准协议的诊断请求报文中新增的字段(例如承载前述的诊断请求报文的标识、第一指示信息、第二指示信息、和第三指示信息等中的至少一项的字段)均可以认为属于与该诊断请求报文的报文负载关联的报文头，该报文头可作为一个整体增加至该诊断请求报文中。或者，与报文负载关联的报文头中可以仅包括上述新增字段的一部分，例如包括第一指示信息、第二指示信息和第三指示信息等。并且，新增的不同信息在该诊断请求报文中的承载位置可以相邻或不相邻，下文中将结合具体报文结构示例进行说明，在此暂不赘述。

在一些情形下，相关车载诊断标准协议的基础通信协议(例如DoIP协议)中，报文长度允许超过4GB(UDS data区，0～2

本申请实施例中，通过确定诊断请求报文与诊断响应报文的匹配关系，提高车辆远程诊断分析的准确性，一种可能的实现方式是，在相关车载诊断标准协议中引入分包机制，并据此制定新的报文格式(为便于区分，可表示为第三报文格式)，使得车辆100侧的诊断代理装置154之间可以基于所述第三报文格式确定待向远程诊断装置210反馈的诊断响应报文序列(包含同一诊断请求报文对应的多个诊断响应报文)，从而远程诊断装置210可以基于对同一诊断请求报文关联的诊断响应报文序列进行解析，提升车辆远程诊断结果的准确性。

实施时，该分包机制可与前述的长诊断指令序列机制采用相同的报文格式。例如，可以在诊断响应报文中增加第四指示信息、第五指示信息、和第六指示信息等。其中，该第四指示信息可用于指示诊断响应报文中是否包含与诊断响应报文的报文负载关联的报文头，在诊断响应报文不包含该报文头的情况下，远程诊断装置210可基于相关车载标准协议的报文格式面对该诊断响应报文中的报文负载进行解析，获得车辆远程诊断结果；在该诊断响应报文包含该报文头的情况下，远程诊断装置210可基于所述第三报文格式，对于报文负载关联的报文头以及报文负载进行解析，获得车辆远程诊断结果。第五指示信息可用于指示诊断响应报文是否属于一组诊断响应报文序列，在该诊断响应报文为单条响应报文，即不属于一组诊断响应报文序列的情况下，远程诊断装置210可基于相关车载标准协议的报文格式，对该诊断响应报文中的报文负载进行解析，获得车辆远程诊断结果；在该诊断响应报文属于一组诊断响应报文序列的情况下，该远程诊断装置210可基于所述第三报文格式，对属于同一组诊断响应报文序列的至少两个诊断响应报文进行组包处理，获得车辆远程诊断结果。第六指示信息可用于指示以下属性信息：一组诊断响应报文序列的标识、一组诊断响应报文中的诊断响应报文的数量和诊断响应报文在一组诊断响应报文序列中的序号。相应地，远程诊断装置210可以根据所述第六指示信息，具体执行对属于同一组诊断响应报文序列的至少两个诊断响应报文的组包处理和解析操作。第四指示信息、第五指示信息、和第六指示信息等的具体实现，可以上述第一指示信息、第二指示信息、和第三指示信息等相同或相似，在此不再赘述。

由此，本申请实施例通过在相关车载诊断标准协议中引入上述会话机制、长诊断指令序列机制、分包机制等，有助于在车辆远程诊断场景中，较为准确地确定诊断请求报文与诊断响应报文的匹配关系，提升远程诊断分析的准确性。

为了便于理解，下面以DoIP标准协议和DoIP报文为例，对本申请实施例的新的报文格式进行介绍。

图3示出了基于DoIP ISO 13400标准协议的DoIP报文的示意图。参阅图3所示，该DoIP报文为以太网报文的负载(payload)字段的一部分，在该以太网报文中还可以包括物理资源块(Physical Recourse Block，PRB)、目标地址(Destination or Target Address，DA)、源地址(Source Address，SA)、类型(type)、循环冗余校验(cyclic redundancycheck，CRC)等字段，在该以太网报文的负载字段中还可以包括网际协议(InternetProtocol，IP)报文头、传输控制协议(Transmission Control Protocol，TCP)/用户数据报协议(User Datagram Protocol，UDP)报文头、以及DoIP报文，在该DoIP报文中可以包括DoIP报文的报文头(header)和负载(payload)，该DoIP报文的报文头中可以包括以下字段：协议版本(protocol version)(1字节(byte))、反向协议版本(inverse protocolversion)(1byte)、负载类型(payload type)(2byte)、负载长度(payload length)(4byte)、负载(payload)(N byte，根据实际的负载类型，负载数据会不同)，这些字段在该DoIP报文中占据的数据字节以及相关描述如下表1所示。

表1

需要说明的是，图3仅是对以太网报文中DoIP报文的报文格式的简单说明，具体可参见DoIP标准协议，在此不再赘述。

本申请实施例中，以图3所示的DoIP报文为例，所设计的新的报文格式，可以包括但不限于以下三种情形：

①：在DoIP报文的报文头之前增加相关字段；

②：在DoIP报文的报文头之后、报文负载之前增加相关字段；

③：在DoIP报文的报文负载之后增加相关字段。

应理解，图3中仅以箭头表示新增的字段在DoIP报文中的可能位置，并不限定相关字段的具体实现方式。

在上述三种情形下，本申请实施例所设计的新的报文格式可以包括：

第一报文格式：在消息方向(即消息从发送方指向接收方的方向)为云诊断应用客户端指向车辆的情况下，远程诊断装置210在诊断请求报文增加诊断请求报文的标识。在消息方向为车辆指向云诊断应用客户端的情况下，车辆侧的诊断代理装置154根据诊断请求报文向远程诊断装置210反馈的诊断响应报文中包含该诊断请求报文的标识，如图4所示。

第二报文格式：在消息方向为云诊断应用客户端指向车辆的情况下，远程诊断装置210在诊断请求报文增加诊断请求报文的标识(可选)、第一指示信息、第二指示信息和第三指示信息等。在消息方向为车辆指向云诊断应用客户端的情况下，车辆侧的诊断代理装置154向远程诊断装置210反馈的诊断响应报文中可以包含诊断请求报文的标识(可选)、第四指示信息、第五指示信息和第六指示信息等，如图5所示。其中，第一/二/三/四/五/六指示信息的具体含义可参见上文的相关描述，在此不再赘述。需要说明的是，图5中虚线框表示该诊断请求报文的标识是可选信息。

第三报文格式：在消息方向为云诊断应用客户端指向车辆的情况下，远程诊断装置210在诊断请求报文增加诊断请求报文的标识。在消息方向为车辆指向云诊断应用客户端的情况下，车辆侧的诊断代理装置154向远程诊断装置220发送的诊断响应报文中增加相应的诊断请求报文的标识、以及增加第四指示信息、第五指示信息和第六指示信息等，如图6所示。其中，第四/五/六指示信息的具体含义可参见上文的相关描述，在此不再赘述。需要说明的是，图6中虚线框表示该诊断请求报文中的第一指示信息、第二指示信息第三指示信息等是可选信息。

需要说明的是，上述三种情形及其三种报文格式中，新增的相关字段可以添加至原报文中的相应位置，相应地，报文中各个数据字节的含义以及相关解释说明需要随着在相应数据字节具体承载的内容的变化而更改。例如，在情形①和情形②中，在原报文中增加相关字段后，原报文的报文头和/或报文负载在报文中的位置向后移动，在情形③中，新增相关字段添加至报文负载之后，原报文的报文头和/或报文负载在报文中的位置不变、更改报文的负载长度指示信息。

为了便于理解，下面以情形②中的第二报文格式为例，参阅图7，对新的报文格式中新增各个字段进行解释说明，如下表2所示：

表2

其中，在上述表2中，加粗表示的数据字节8-21中承载有新增的相关字段，含义如下：

1)位于8-11字节的负载序列号，即为前述的诊断请求报文的标识，用于唯一标识该诊断请求报文；或为诊断响应报文中的相应该诊断请求报文的标识(即一对诊断请求报文和诊断响应报文中的负载序列号需要相同)，可用于确定诊断响应报文与相应的诊断请求报文的匹配关系。该负载序列号可以是序列中的累积值，可循环使用。

2)位于12字节的负载用户数据头标识，即为前述的第一指示信息(或第四指示信息)，可用于指示诊断请求报文(或诊断响应报文)中是否包含与报文负载关联的报文头。其中，若该负载用户数据头标识的取值为0x00可以表示报文中不包含与报文负载关联的报文头，若该负载用户数据头标识的取值为0x01可以表示报文中包含与报文负载关联的报文头。

3)位于13字节的用户数据头长度，可用于指示与报文负载关联的报文头的长度，该长度不包含负载用户数据头标识的长度。应理解的是，本申请实施例中，位于13字节的用户数据头长度也可视为第一指示信息的一部分。

4)位于14字节的信息元素标识，即为前述的第二指示信息(或第五指示信息)，可用于指示报文是否属于一组诊断请求报文序列(或诊断响应报文序列)。其中，若该信息元素标识的取值为0x00则表示该报文为单条报文、不属于报文序列；若该信息元素标识的取值为0x01则表示该报文为属于报文序列。

5)位于15字节的信息元素数据长度，可用于指示信息元素数据长度，该长度不包含信息元素标识长度。位于16-21字节的信息元素数据为与报文负载相关的属性信息，基于这些信息元素，在对报文进行解析时，可以知悉报文所属的报文序列、报文序列中的报文数量、报文在相应报文序列中的序号等，有助于确定诊断请求报文与诊断响应报文的匹配关系，提升车辆远程诊断的准确性。15-21字节的内容，可视为前述的第三指示信息(或第六指示信息)。

表2中未示出的位于0-7字节、22-28字节的内容可为表1中位于0-7、8-14的内容，可复用ISO 13400，详见表1和DoIP标准协议，在此不再赘述。或者，本申请实施例中，可以设计新的协议版本和报文格式，相关报文中包含表2所示的字段，在此不再赘述。

需要说明的是，上述仅以DoIP标准协议、DoIP报文为例，对本申请实施例可能涉及的报文格式进行示例说明，应理解，在其它相关车载诊断标准协议中，新的报文格式还可以有其它结构，本申请实施例对此不做限定。图7中仅以矩形框示意性表示报文中可以包含的字段，并不限定字段名称、字段所占据的字节长度等信息。并且，对于新的每种报文格式，可以有相应的协议版本，远程诊断装置210和车辆侧的诊断代理装置154还可以相互协商双方之间通信所采用的协议版本，并基于协商确定的协议版本进行报文传输，在此不再赘述。

根据上述报文格式构造的诊断请求报文和诊断响应报文，通过在相关车载诊断标准协议中引入会话机制、或长诊断指令序列机制、或分包机制等，使得在车辆远程诊断场景中，能够较为准确地匹配诊断请求报文和诊断响应报文的匹配关系，车辆侧的诊断代理装置能够准确地对接收到的一个或多个诊断请求报文进行解析并做出应答，相应地，远程诊断装置能够较为准确地对来自车辆的诊断响应报文进行解析获得诊断分析结果，提升车辆远程诊断分析的准确性。

此外，该方案还可以用于在车辆远程诊断场景中，在远程诊断装置210和车辆侧的诊断代理装置154之间协商多帧诊断请求报文和诊断响应报文的发送、重发、补发机制等。下面结合方法流程图对本申请实施例的车辆远程诊断方法进行介绍。

图8示出了本申请实施例的车辆远程诊断方法的流程示意图。其中，该方法可由图2所示的远程诊断装置210和车辆100侧的诊断代理装置154、各个诊断节点120协同实现。

参阅图8所示，该车辆远程诊断方法可以包括以下步骤：

S801：远程诊断装置210确定第一诊断请求报文，所述第一诊断请求报文用于对所述车辆进行远程诊断。

本申请实施例中，远程诊断装置210可以在前述的任一报文格式中确定所需的报文格式，然后根据所确定的报文格式确定该第一诊断请求报文。

示例的，该第一诊断请求报文中可以包含该诊断请求报文的标识。可选地，该第一诊断请求报文中可以包含负载和第一指示信息，该第一指示信息可用于指示第一诊断请求报文中是否包含与所述负载关联的报文头。可选地，该第一诊断请求报文中还可以包含第二指示信息，该第二指示信息可用于指示所述第一诊断请求报文是否属于一组诊断请求报文序列。可选地，该第一诊断请求报文中还可以包含第三指示信息，该第三指示信息可用于指示以下属性信息：所述一组诊断请求报文序列的标识、所述一组诊断请求报文序列中的诊断请求报文的数量和所述第一诊断请求报文在所述一组诊断请求报文序列中的序号。详细报文内容可参见上述关于报文格式的相关描述，在此不再赘述。

S802：远程诊断装置210向车辆发送第一诊断请求报文。相应地，车辆100侧的诊断代理装置接收来自远程诊断装置的第一诊断请求报文。

本申请实施例中，诊断代理装置可以称为车辆侧的车载诊断边缘节点，该诊断代理装置可以根据来自远程诊断装置的诊断请求报文激活相应的诊断节点(node)，并由各个诊断节点从关联的ECU获得车辆的诊断数据。

在一个示例中，该诊断代理装置可以部署在车辆侧的T-Box中，该情形下，诊断代理装置可以对接收到的第一诊断请求报文进行解析，并将解析结果透传给车载网关，车载网关可以向相应的诊断节点发送该解析结果，由相应的诊断节点基于该解析结果，通过汽车总线与各个ECU进行信息交互(例如诊断指令)，从而获得车辆的诊断数据。

在另一个示例中，该诊断代理装置可以部署在车辆侧的车载网关中，该情形下，T-Box接收到第一诊断请求报文后，作为移动网络路由向车载网关透传该第一诊断请求报文，由车载网关中部署的诊断代理装置对接收到的第一诊断请求报文进行解析，并将解析结果发送给相应的诊断节点，由相应的诊断节点基于该解析结果，通过汽车总线与各个ECU进行信息交互(例如诊断指令)，从而获得车辆的诊断数据。

S803：车辆100侧的诊断代理装置154根据所述第一诊断请求报文从车辆100侧的各个诊断节点120获取车辆的诊断数据。

S804：车辆100侧的诊断代理装置154根据所述第一诊断请求报文的标识和所述车辆的诊断数据，确定第一诊断响应报文。

本申请实施例中，所述诊断数据是根据所述第一诊断请求报文获取的。例如，诊断代理装置154可以将第一诊断请求报文涉及的诊断指令发送给相应的诊断节点120，诊断节点120可以将诊断指令下发给具体的ECU，ECU可以根据诊断指令进行车辆数据采集获得车辆的诊断数据，ECU可以将采集到的诊断数据返回给诊断节点120。诊断节点1220可将获得的诊断数据发送给诊断代理装置154，诊断代理装置154可以根据所采用的报文格式，对第一诊断请求报文的标识和车辆的诊断数据进行组织、打包，得到所述第一诊断响应报文。

S805：车辆100侧的诊断代理装置154向所述远程诊断装置210发送所述第一诊断响应报文。相应地，远程诊断装置210接收所述车辆的第一诊断响应报文。

本申请实施例中，该第一诊断响应报文中可以包含所述第一诊断请求报文的标识、以及车辆的诊断数据，远程诊断装置210根据该标识，可以知悉该第一诊断响应报文具体是对哪一个第一诊断请求报文的应答，故而远程诊断装置210通过该第一诊断响应报文中的诊断数据进行解析，可以准确地获得第一诊断请求报文对应的车辆远程诊断结果，实现对车辆的远程实时诊断。可选地，远程诊断装置210还可以输出诊断结果数据。例如，通过用户界面、或扬声器等输出设备输出该诊断结果，本申请实施例对此不做限定。

需要说明的是，在实施上述S801之前，远程诊断装置210可以通过向车辆发起连接请求，来与车辆建立安全的通信连接，从而基于该通信连接激活远程诊断装置210和车辆之间的远程诊断链路，以便远程诊断装置210对该车辆进行远程诊断。实施时，远程诊断装置210可向车辆发送激活车载诊断协议路由的激活请求报文，车辆侧的诊断代理装置154可基于该激活请求报文激活车辆侧的M个诊断节点。相应地，诊断代理装置154可向远程诊断装置210发送激活车载诊断协议路由的激活响应报文。在远程诊断装置210与车辆的各个诊断节点之间的远程诊断链路已激活的情况下，该远程诊断装置210可以向相应诊断节点发送诊断请求报文，以对车辆进行远程故障诊断。

在实施S805之后，若要结束对车辆的远程诊断，远程诊断装置可向车辆发送关闭车载诊断协议路由的关闭请求报文，车辆侧的诊断代理装置可基于该关闭请求报文关闭车辆侧的各个诊断节点，相应地，诊断代理装置154可向远程诊断装置210发送关闭响应报文，在远程诊断装置210与车辆的各个诊断节点之间的远程诊断链路关闭的情况下，该远程诊断装置210无法对车辆进行远程实时诊断，若需要对车辆进行远程实时诊断，则需基于前述方法重新激活与车辆的各个诊断节点之间的远程诊断链路。

此外，本申请实施例中，根据第一诊断请求报文和/或第一诊断响应报文采用图4-图6所示的不同格式的报文，车辆侧的诊断代理装置154或远程诊断装置210对相应报文的处理方式不同。下面基于图4-图6示出的不同报文格式，对S801-S805中部分或全部步骤的可能实现方式进行示例说明。

示例一：第一诊断请求报文为单个诊断请求报文(即不属于一组诊断请求报文序列)，第一诊断响应报文为单个诊断响应报文(即不属于一组诊断响应报文序列)。

在该示例中，第一诊断请求报文中可以仅新增第一诊断请求报文的标识(如图4所示)，或者，第一诊断请求报文中可以新增第一指示信息，该第一指示信息的取值可以为0x00，表示该第一诊断请求报文中不包含与报文负载关联的报文头。相应地，第一诊断响应报文中可以仅新增第一诊断请求报文的标识(如图4所示)，或者，第一诊断响应报文中可以新增第四指示信息，该第四指示信息的取值可以为0x00，表示该第一诊断请求报文中不包含与报文负载关联的报文头。

示例二：第一诊断请求报文为单个诊断请求报文(即不属于一组诊断请求报文序列)，第一诊断响应报文属于一组诊断响应报文序列。

在该示例中，第一诊断请求报文中可以仅新增第一诊断请求报文的标识(如图4所示)，或者，第一诊断请求报文中可以新增第一指示信息，该第一指示信息的取值可以为0x00，表示该第一诊断请求报文中不包含与报文负载关联的报文头。

诊断代理装置154可以对车辆的诊断数据进行分包多次发送：

S804中，诊断代理装置154可以在车辆的诊断数据满足第一分包条件时，根据所述第一诊断请求报文的标识和所述诊断数据，确定至少两个诊断响应报文。S805中，诊断代理装置154可以向所述远程诊断装置210发送一组诊断响应报文序列，包括所述至少两个诊断响应报文。其中，所述至少两个诊断响应报文包括所述第一诊断响应报文，所述至少两个诊断响应报文属于同一组诊断响应报文序列，所述至少两个诊断响应报文中均包含所述第一诊断请求报文的标识，每个诊断响应报文中还包括第四指示信息、第五指示信息和第六指示信息，以指示每个诊断响应报文与所属诊断响应报文序列的关联关系、报文负载的相关属性信息等。第四/五/六指示信息的含义可参见上述的相关描述，在此不再赘述。

相应地，远程诊断装置210可以接收来自车辆的至少两个诊断响应报文，并对属于同一组诊断响应报文序列的至少两个诊断响应报文进行组包处理，所述至少两个诊断响应报文包括所述第一诊断响应报文。

示例三：第一诊断请求报文属于一组诊断请求报文序列，第一诊断响应报文属于一组诊断响应报文序列。

在该示例中，诊断任务例如可以根据一组连续的诊断指令事务触发的，远程诊断装置可以根据该组连续的诊断指令事务确定一组诊断请求报文序列(例如每个诊断指令事务对应一个诊断请求报文)，该组诊断请求报文序列中包括至少两个诊断请求报文，所述至少两个诊断请求报文包括所述第一诊断请求报文，该组诊断请求报文序列中的每个诊断请求报文具有其唯一标识。每个诊断请求报文中还包含相应的第一指示信息、第二指示信息和第三指示信息，以指示每个诊断请求报文与所属诊断请求报文序列的关联关系、报文负载的相关属性信息等。第一/二/三指示信息的含义可参见上述的相关描述，在此不再赘述。

相应地，车辆侧的诊断代理装置154可以接收来自远程诊断装置210的至少两个诊断请求报文，并对属于同一诊断请求报文序列的至少两个诊断请求报文进行组包处理，所述至少两个诊断请求报文包括所述第一诊断请求报文。

针对一组诊断请求报文序列中的至少两个诊断请求报文，车辆侧的诊断代理装置154可以根据每个诊断请求报文的标识以及相应的诊断数据，确定该诊断请求报文对应的诊断响应报文。所述至少两个诊断请求报文各自对应的诊断响应报文可以组成一组诊断响应报文序列，诊断代理装置154可以向远程诊断代理装置反馈该组诊断响应报文序列。其中，对于每个诊断请求报文对应的诊断数据，若该部分诊断数据满足第一分包条件(例如数据量超过诊断响应报文的数据包容量限制)时，诊断代理装置154可根据该部分诊断数据确定至少两个诊断响应报文，即将该诊断请求报文对应的诊断数据分包，所述至少两个诊断响应报文属于同一组诊断响应报文序列，所述至少两个诊断响应报文中均包含同一诊断请求报文(例如第一诊断请求报文)的标识。

应理解，本申请实施例中，一个诊断请求报文对应的至少两个诊断响应报文属于一组诊断响应报文序列。为便于区分，若一个诊断请求报文属于一组诊断请求报文序列、且该诊断请求报文对应至少两个诊断响应报文，该至少两个诊断响应报文所属的一组诊断响应报文序列可以认为是，该组诊断请求报文序列对应的诊断响应报文序列的子序列。

示例四：第一诊断请求报文属于一组诊断请求报文序列。

在该示例中，若因网络延迟、网络拥塞等不确定性，导致车辆侧的诊断代理装置154暂时只接收到一组诊断请求报文序列(例如第一诊断请求报文所属的一组诊断请求报文序列)中的部分诊断请求报文，对于该组诊断请求报文序列中未被接收到的其它诊断请求报文(例如第一诊断请求报文)，该诊断代理装置154可以根据已经接收到的诊断请求报文中的相关指示信息，确定该组诊断请求报文序列的标识、该组诊断请求报文序列中未接收到的诊断请求报文(例如第一诊断请求报文)的序号，并根据该组诊断请求报文序列的标识、以及所述第一诊断请求报文在所述一组诊断请求报文序列中的序号，指示所述远程诊断装置发送所述第一诊断请求报文。即，诊断代理装置154可以指示远程诊断装置210发送或补发或重发该第一诊断请求报文。

实施时，在S801之后，诊断代理装置154可以向远程诊断装置210发送指示信息，该指示信息可用于指示一组诊断请求报文序列的标识、以及所述第一诊断请求报文在所述一组诊断请求报文序列中的序号。相应地，远程诊断装置210可以接收该指示信息，并根据所述车辆指示的一组诊断请求报文序列的标识、以及所述第一诊断请求报文在所述一组诊断请求报文序列中的序号，向所述车辆发送所述第一诊断请求报文。由此，S803、S804中，诊断代理装置154可以对属于同一组诊断请求报文序列的至少两个诊断请求报文进行组包处理，所述至少两个诊断请求报文包括所述第一诊断请求报文。

示例五：第一诊断响应报文属于一组诊断响应报文序列。

在该示例中，若因网络延迟、网络拥塞等不确定性，导致远程诊断装置210暂时只接收到一组诊断响应报文序列(例如第一诊断响应报文所属的一组诊断响应报文序列)中的部分诊断响应报文，对于该组诊断响应报文序列中未被接收到的其它诊断响应报文(例如第一诊断响应报文)，该远程诊断装置210可以根据已经接收到的诊断响应报文中的相关指示信息，确定该组诊断响应报文序列的标识、该组诊断响应报文序列中未接收到的诊断响应报文(例如第一诊断响应报文)的序号，并根据该组诊断响应报文序列的标识、以及所述第一诊断响应报文在所述一组诊断响应报文序列中的序号，指示车辆侧的诊断代理装置154发送所述第一诊断响应报文。即，诊断代理装置154可以指示远程诊断装置210发送或补发或重发该第一诊断响应报文。

实施时，在S805之后，远程诊断装置210可以向车辆侧的诊断代理装置154发送指示信息，该指示信息可用于指示一组诊断响应报文序列的标识、以及所述第一诊断响应报文在所述一组诊断响应报文序列中的序号。相应地，诊断代理装置154可以接收该指示信息，并根据所述车辆指示的一组诊断响应报文序列的标识、以及所述第一诊断响应报文在所述一组诊断响应报文序列中的序号，向所述远程诊断装置210发送所述第一诊断响应报文。由此，远程诊断装置210可以对属于同一组诊断响应报文序列的至少两个诊断响应报文进行组包处理，所述至少两个诊断响应报文包括所述第一诊断请求报文。

由此，通过上述方法及示例，可以对相关车载诊断标准协议的报文格式改进，在报文中增加相关字段，以引入会话机制、长诊断指令序列机制、分包机制等，以减少因网络延迟、网络阻塞等不确定性的情况带来的报文乱序的问题，有助于在车辆远程诊断场景中，较为准确地确定诊断请求报文与诊断响应报文的匹配关系，提升远程诊断分析的准确性，以满足未来对智能汽车远程诊断/刷写升级技术的发展需求。

本申请实施例还提供了一种车辆远程诊断装置，用于执行上述实施例中车辆侧的诊断代理装置所执行的方法，相关特征可参见上述方法实施例，在此不再赘述。

如图9所示，该装置900可以包括：接收单元901，用于接收来自远程诊断装置的第一诊断请求报文，所述第一诊断请求报文用于对所述车辆进行远程诊断，所述第一诊断请求报文中包含所述第一诊断请求报文的标识；处理单元902，用于根据所述第一诊断请求报文的标识和所述车辆的诊断数据，确定第一诊断响应报文，所述诊断数据是根据所述第一诊断请求报文获取的；发送单元903，用于向所述远程诊断装置发送所述第一诊断响应报文。具体实现方式，请参考图2至图8所示实施例中的详细描述，这里不再赘述。

本申请实施例还提供了一种车辆远程诊断装置，用于执行上述方法实施例中远程诊断装置所执行的方法，相关特征可参见上述方法实施例，在此不再赘述。

如图10所示，在一个示例中，该装置1000可以包括：处理单元1001，用于确定第一诊断请求报文，所述第一诊断请求报文用于对所述车辆进行远程诊断，所述第一诊断请求报文中包含所述第一诊断请求报文的标识；发送单元1002，用于向所述车辆发送第一诊断请求报文；接收单元1003，用于接收所述车辆的第一诊断响应报文，所述第一诊断响应报文中包含所述第一诊断请求报文的标识、以及所述车辆的诊断数据，所述诊断数据是根据所述第一诊断请求报文获取的。具体实现方式，请参考图2至图8所示实施例中的详细描述，这里不再赘述。

需要说明的是，本申请实施例中对单元的划分是示意性的，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式。在本申请的实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)或处理器(processor)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。

在一个简单的实施例中，本领域的技术人员可以想到上述实施例中的远程诊断装置或车辆侧的诊断代理装置均可采用图11所示的形式。

如图11所示的装置1100，包括至少一个处理器1110、存储器1120，可选的，还可以包括通信接口1130。

本申请实施例中不限定上述处理器1110以及存储器1120之间的具体连接介质。

在如图11的装置中，还包括通信接口1130，处理器1110在与其他设备进行通信时，可以通过通信接口1130进行数据传输。

当远程诊断装置采用图11所示的形式时，图11中的处理器1110可以通过调用存储器1120中存储的计算机执行指令，使得设备1100可以执行上述任一方法实施例中远程诊断装置执行的方法。

当车辆侧的诊断代理装置采用图11所示的形式时，图11中的处理器1110可以通过调用存储器1120中存储的计算机执行指令，使得设备1100可以执行上述任一方法实施例中诊断代理装置执行的方法。

本申请实施例还涉及一种芯片系统，该芯片系统包括处理器，用于调用存储器中存储的计算机程序或计算机指令，以使得该处理器执行上述任一实施例的方法。

在一种可能的实现方式中，该处理器通过接口与存储器耦合。

在一种可能的实现方式中，该芯片系统还包括存储器，该存储器中存储有计算机程序或计算机指令。

本申请实施例还涉及一种处理器，该处理器用于调用存储器中存储的计算机程序或计算机指令，以使得该处理器执行上述任一实施例所述的方法。

应明白，本申请的实施例可提供为方法、系统、或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

显然，本领域的技术人员可以对本申请实施例进行各种改动和变型而不脱离本申请实施例范围。这样，倘若本申请实施例的这些修改和变型属于本申请权利要求及其等同技术的范围之内，则本申请也意图包含这些改动和变型在内。