一种远程诊断方法、装置及相关设备与流程

1.本技术实施例涉及一种计算机领域，尤其涉及一种远程诊断方法、装置及相关设备。


背景技术：

2.随着车载以太网技术的发展以及5g技术的逐步成熟，使用通过互联网协议进行诊断(doip，diagnostic over internet protocol)，实现汽车远程实时诊断，会极大的减少车辆返厂的次数和时间。甚至，用户和汽车厂商可以在任意时间和地点，第一时间获取车辆的实时状况。如果存在危害驾驶安全的故障，也会及时反馈给用户进行安全保护；同时也为汽车厂商的返厂维护提供最及时最有效的数据。
3.但是，现有的doip远程诊断存在只能支持一路网际协议(ip，internet protocol)的不足，而造成对于有些车辆无法进行doip远程诊断。例如有很多车型，车辆端会有多个电子控制单元(ecu，electronic control unit)同时和诊断设备通讯，每个ecu都有独立的网卡，独立的ip地址，诊断设备会建立多个连接，和不同的ecu并行的进行通讯。但是，通过该方法，在同一时间只能转发一个ip地址的数据，如果车辆端上有多个ip地址，诊断设备是没有办法模拟的，从而导致诊断失败。


技术实现要素：

4.本技术实施例提供了一种远程诊断方法，用于实现多通道并行的数据交互。
5.本技术实施例第一方面提供了一种远程诊断方法，应用于远程诊断系统中的客户端；所述客户端分别与车辆、服务端通信连接，所述服务端与诊断设备通信连接；所述方法包括：
6.获取所述诊断设备通过所述服务端发送的第一udp报文；
7.解析所述第一udp报文，以获取对应的第一ip地址；
8.根据所述第一ip地址确定对应的第一数据传输通道；
9.通过所述第一数据传输通道将所述第一udp报文发送至所述车辆上与所述第一ip地址对应的电子控制单元。
10.可选地，所述方法还包括：
11.获取所述车辆广播的第二udp报文；
12.解析所述第二udp报文，以获取对应的第二ip地址；
13.若所述第二ip地址为新增ip地址，则与所述第二ip地址对应的电子控制单元之间创建第二数据传输通道。
14.可选地，在所述创建第二数据传输通道之后，所述方法还包括：
15.将所述第二udp报文以及对应的所述第二数据传输通道的标识号发送至所述服务端。
16.可选地，所述获取所述车辆广播的第二udp报文之前，所述方法还包括：
17.检测与所述车辆的网络诊断协议doip的网络是否连接，若是，执行所述获取所述车辆广播的第二udp报文的步骤。
18.本技术实施例第二方面提供了一种远程诊断方法，应用于远程诊断系统中的服务端；所述服务端分别与诊断设备、客户端通信连接，所述客户端与车辆通信连接；所述方法包括：
19.获取所述车辆通过所述客户端发送的第三用户数据报协议udp报文；
20.解析所述第三udp报文，以获取对应的第三ip地址；
21.根据所述第三ip地址确定对应的第三数据传输通道；
22.将所述第三udp报文通过所述第三数据传输通道发送至所述诊断设备，以实现所述车辆和所述诊断设备的数据交互。
23.可选地，所述方法还包括：
24.接收所述客户端发送的第二udp报文以及标识号；
25.若所述目标标识号为新增标识号，则与所述诊断设备之间创建与所述新增标识号对应的第二数据传输通道。
26.可选地，所述与所述诊断设备之间创建与所述新增标识号对应的第二数据传输通道包括：
27.创建虚拟网卡；
28.通过所述虚拟网卡广播所述第二udp报文；
29.接收所述诊断设备基于所述第二udp报文携带的第二ip地址发送的socket连接请求；
30.基于所述socket连接请求建立与所述诊断设备之间的第二数据传输通道。
31.本技术实施例第三方面提供了一种远程诊断装置，应用于客户端，包括：
32.获取单元，用于获取所述诊断设备通过所述服务端发送的第一udp报文；
33.解析单元，用于解析所述第一udp报文，以获取对应的第一ip地址；
34.确定单元，用于根据所述第一ip地址确定对应的第一数据传输通道；
35.发送单元，用于通过所述第一数据传输通道将所述第一udp报文发送至所述车辆上与所述第一ip地址对应的电子控制单元。
36.可选地，所述装置还包括：创建单元。
37.所述获取单元，还用于获取所述车辆广播的第二udp报文；
38.所述解析单元，还用于解析所述第二udp报文，以获取对应的第二ip地址；
39.所述创建单元，用于当所述第二ip地址为新增ip地址时，则与所述第二ip地址对应的电子控制单元之间创建第二数据传输通道。
40.可选地，
41.所述发送单元，还用于将所述第二udp报文以及对应的所述第二数据传输通道的标识号发送至所述服务端。
42.可选地，所述装置还包括检测单元。
43.所述检测单元，用于检测与所述车辆的网络诊断协议doip的网络是否连接，若是，执行所述获取所述车辆广播的第二udp报文的步骤。
44.本技术实施例第三方面提供的一种远程诊断装置用于执行第一方面所述的方法。
45.本技术实施例第四方面提供了一种远程诊断装置，应用于服务端，包括：
46.获取单元，用于获取所述车辆通过所述客户端发送的第三用户数据报协议udp报文；
47.解析单元，用于解析所述第三udp报文，以获取对应的第三ip地址；
48.确定单元，用于根据所述第三ip地址确定对应的第三数据传输通道；
49.发送单元，用于将所述第三udp报文通过所述第三数据传输通道发送至所述诊断设备，以实现所述车辆和所述诊断设备的数据交互。
50.可选地，所述装置还包括：接收单元及创建单元。
51.所述接收单元，用于接收所述客户端发送的第二udp报文以及标识号；
52.所述创建单元，用于当所述目标标识号为新增标识号时，则与所述诊断设备之间创建与所述新增标识号对应的第二数据传输通道。
53.可选地，所述装置还包括广播单元及建立单元。
54.所述创建单元，具体用于创建虚拟网卡；
55.所述广播单元，用于通过所述虚拟网卡广播所述第二udp报文；
56.所述接收单元，具体用于接收所述诊断设备基于所述第二udp报文携带的第二ip地址发送的socket连接请求；
57.所述建立单元，用于基于所述socket连接请求建立与所述诊断设备之间的第二数据传输通道。
58.本技术实施例第四方面提供的一种远程诊断装置用于执行第二方面所述的方法。
59.本技术实施例第五方面提供了一种远程诊断设备，包括：
60.中央处理器，存储器，输入输出接口，有线或无线网络接口以及电源；
61.所述存储器为短暂存储存储器或持久存储存储器；
62.所述中央处理器配置为与所述存储器通信，并执行所述存储器中的指令操作以执行第一方面或第二方面中任一方法所述的方法。
63.本技术实施例第六方面提供了一种计算机可读存储介质，其特征在于，所述计算机可读存储介质包括指令，当所述指令在计算机上运行时，使得计算机执行第一方面或第二方面中任一方法所述的方法。
64.从以上技术方案可以看出，本技术实施例具有以下优点：
65.本技术实施例提出了一种远程诊断方法，可以解析诊断设备通过服务端向客户端发送的udp报文，从而获取ip地址，以此就可根据ip地址确定车辆与客户端之间的数据传输通道。在本技术中，客户端与车辆中不同的电子控制单元设置有不同的数据传输通道，每个电子控制单元对应一个数据传输通道，从而实现车辆与诊断设备之间每一通道传递一个ip地址的数据，不同的通道互不影响。
附图说明
66.为了更清楚地说明本技术实施例中的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本技术中记载的一些实施例，对于本领域普通技术人员来讲，还可以根据这些附图获得其他的附图。
67.图1为本技术实施例公开的一种远程诊断方法的设备架构示意图；
68.图2为本技术实施例公开的一种远程诊断方法的交互流程图；
69.图3为本技术实施例公开的另一种远程诊断方法的交互流程图；
70.图4为本技术实施例公开的一种远程诊断装置的结构示意图；
71.图5为本技术实施例公开的另一种远程诊断装置的结构示意图；
72.图6为本技术实施例公开的一种远程诊断设备的结构示意图。
具体实施方式
73.下面将结合本技术实施例中的附图，对本技术实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本技术一部分实施例，而不是全部的实施例。基于本技术中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本技术保护的范围。
74.本技术实施例提供了一种远程诊断方法，用于实现多通道并行的数据交互。
75.本方法旨在解决现有的doip远程诊断只能支持一路ip的不足，而造成对于有些车辆无法进行doip远程诊断。例如某车厂的很多车型，车辆端会有多个ecu同时和诊断设备通讯，每个ecu都有独立的网卡，独立的ip地址，诊断设备会建立多个socket连接，和不同的ecu并行的进行通讯。其中，doip，是一种基于ip协议的诊断方式，也就是在统一诊断服务(uds，unified diagnostic services)基础上，通过传输控制协议(tcp，transfer control protocol)或ip及以太网来进行车辆诊断的方式。
76.需要了解的是，ecu，中文名称一般称为电脑控制模组，或电子控制单元，俗话叫行车电脑、车载电脑等。ecu可以说是现代汽车的核心电子元件之一。打个比方，汽车的ecu，就相当于人的大脑、电脑的cpu。ecu就是汽车的大脑神经中枢系统。一般装于驾驶座仪表板下方或雨刷连动杆附近。ecu的作用是，随时监控着输入的各种数据(比如刹车、换挡等)和汽车运行的各种状态(加速、打滑、油耗等)，并按照预先设计的程序计算各种传感器送来的信息，经过处理以后，把各个参数发送给各相关的执行机构，执行各种预定的控制功能。举个例子，ecu根据汽车传感器传来的信号，进行分析、预算、处理和储存后确定最佳喷油量，控制喷油器燃油喷射量，让汽车可以一直保持最佳空燃比，进而提高经济性、动力性和减少尾气的排放。最初的ecu是用来控制发动初的点火和喷油的，而随着轿车电子化自动化的提高，ecu的控制范围也是越来越多，例如灯光控制、安全气襄控制、燃油加热控制、排气控制、制动控制、废气再循环系统(egr，exhaust gas recirculation)等。为方便描述，后续不再对ecu的具体功能进行赘述。
77.还可以理解的是，在本技术实施例中的socket连接，也就是套接字socket，是通信的基石，是支持tcp或ip协议的网络通信的基本操作单元。它是网络通信过程中端点的抽象表示，包含进行网络通信必须的五种信息：连接使用的协议，本地主机的ip地址，本地进程的协议端口，远地主机的ip地址，远地进程的协议端口。应用层通过传输层进行数据通信时，tcp会遇到同时为多个应用程序进程提供并发服务的问题。多个tcp连接或多个应用程序进程可能需要通过同一个tcp协议端口传输数据。为了区别不同的应用程序进程和连接，许多计算机操作系统为应用程序与tcp或ip协议交互提供了socket接口。应用层可以和传输层通过socket接口，区分来自不同应用程序进程或网络连接的通信，实现数据传输的并发服务。为方便描述，后续不再对socket进行赘述，在本技术实施例中，socket主要起到一
种通信通道的作用。
78.请参阅图1，图1为本技术实施例公开的一种基于远程诊断的设备架构示意图。
79.在doip远程诊断中常常使用下面的设备架构，该设备架构通常包括云平台100，c端接头101，车辆102，b端接头103及诊断设备104。其中，车辆102与c端接头相连，诊断设备104与b端接头103相连，云平台100通过网络internet分别与c端接头101和b端接头103相连。
80.在本技术实施例中，c端接头101即为前述部分所描述的客户端，也就是远程诊断的客户端。b端接头103即为前述部分所描述的服务端，也就是远程诊断的服务端。客户端发布远程诊断的需求，请求服务，服务端提供服务。
81.其中，云平台100可以理解为一种通讯网络，上述云平台100可以是独立的物理服务器，也可以是多个物理服务器构成的服务器集群或者分布式系统，还可以是提供云数据库、云服务、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、cdn、以及大数据和人工智能平台等基础云计算服务的云平台。在本技术实施例中，云平台100主要作为b端接头103与c端接头101进行数据交互的通道而存在，为方便理解，后续不再对云平台100的作用进行赘述。
82.在本技术实施例中，c端接头101主要是c端和车辆102连接的一个以太网卡，不难理解的，c端接头101还可以是其他设备，本技术实施例并不对c端接头101的具体设备进行限制，后续也不在对此进行赘述。
83.车辆102主要包含车辆ecu或网关。不难理解的，车辆102还可以包括其他设备，本技术实施例并不对车辆102所包含的具体设备进行限制，后续也不在对此进行赘述。同时也为了方便描述，后续对于车辆102的部分，仅以车辆ecu进行举例说明，后续不再对此进行赘述。
84.b端接头103主要是b端和诊断设备104连接的一个以太网卡，因为在车辆102上有多个ecu，而b端接头103物理上只有一个网卡用于doip通讯，所以b端接头103需要对应每一个车辆102上的ecu创建一个虚拟网卡。每一个虚拟网卡就是模拟一个车辆102上的ecu。不难理解的，b端接头103还可以是其他设备，本技术实施例并不对b端接头103的具体设备进行限制，后续也不在对此进行赘述。
85.诊断设备104是一种能迅速准确査明汽车、总成和机构的技术状况，并得出可靠结论的不解体检验测试机械设备。主要有车轮平衡器、灯光检验仪、反力式制动试验台、底盘测功机、侧滑试验台、前轮定位仪、发动机试验台、废气分析仪、排气烟度计和噪声计等。在本技术实施例中，诊断设备104主要对车辆102上ecu所得到的车辆数据进行处理，为方便理解，后续再对诊断设备104的功能进行赘述。
86.请参阅图2，图2为本技术实施例公开的一种远程诊断方法的交互流程图。包括步骤201-步骤208。
87.201、服务端向客户端发送第一udp报文。
88.服务端获取到诊断设备发送的第一用户数据报协议(udp，user datagram protocol)报文后，就会将获取到的第一udp报文通过网络将该udp报文透传给客户端，从而客户端便可接收到诊断设备发送的第一udp报文。
89.202、客户端解析第一udp报文，以获取对应的第一ip地址。
90.客户端接收到第一udp报文后，便会对该第一udp报文进行解析，从而获取到第一udp报文中所携带的第一ip地址，需要理解的是，该第一ip地址与第一udp报文存在关联关系。
91.203、客户端根据第一ip地址确定对应的第一数据传输通道。
92.客户端获取到第一ip地址后，会根据第一ip地址搜寻本地的存储空间，从而找到携带有第一ip地址标识的第一数据传输通道。对应的，客户端便可根据第一ip地址确定对应的第一数据传输通道。
93.204、客户端通过第一数据传输通道将第一udp报文发送至车辆上与第一ip地址对应的电子控制单元。
94.当客户端确定好第一数据传输通道且接收到服务端转发过来的第一udp报文后，便可通过第一数据传输通道将第一udp报文发送给车辆。具体的，车辆上可以具备多个电子控制单元ecu，每一个ecu都有自己特定的ip地址。由此，对应的，客户端通过第一数据传输通道将第一udp报文发送给与第一ip地址对应的ecu，从而实现车辆与诊断设备之间的数据交互。
95.205、客户端向服务端发送第三udp报文。
96.客户端获取到车辆发送的第三udp报文后，就会将获取到的第三udp报文通过网络将该第三udp报文透传给服务端，从而服务端便可接收到诊断设备发送的第三udp报文。
97.可以理解的是，在本实施例中第三udp报文与第一udp报文可以存在关联，换言之，客户端向服务端发送的第三udp报文后，服务端可以将第三udp报文经过一系列的步骤处理后，形成第一udp报文，从而将第一udp报文通过网络透传给客户端。具体此处不对第一udp报文与第三udp报文之间的关联关系进行限制，第一udp报文与第三udp报文也可以不存在关联关系，此时可以不执行步骤201-步骤204。为方便描述，后续不再对此进行赘述。
98.206、服务端解析第三udp报文，以获取对应的第三ip地址。
99.服务端接收到第三udp报文后，便会对该第三udp报文进行解析，从而获取到第三udp报文中所携带的第三ip地址，需要理解的是，该第三ip地址与第三udp报文存在关联关系。还需要理解的是，若第一udp报文与第三udp报文存在关联，那么对应的，第一ip地址与第三ip地址也会存在关联。还可以理解的是，第一ip地址与第三ip地址在一定条件下，第一ip地址可以与第三ip地址为同一ip地址。具体此处并不对第一ip地址或第三ip地址的关联关系进行限制，后续也不再对此进行赘述。
100.207、服务端根据第三ip地址确定对应的第三数据传输通道。
101.服务端获取到第三ip地址后，会根据第三ip地址搜寻本地的存储空间，从而找到携带有第三ip地址标识的第三数据传输通道。对应的，服务端便可根据第三ip地址确定对应的第三数据传输通道。
102.208、服务端将第三udp报文通过第三数据传输通道发送至诊断设备，以实现车辆和诊断设备的数据交互。
103.当服务端确定好第三数据传输通道且接收到服务端转发过来的第三udp报文后，便可通过第三数据传输通道将第三udp报文发送给诊断设备。对应的，服务端将第三udp报文通过与第三ip地址对应的第三数据传输通道发送给争端设备，从而实现车辆与诊断设备之间的数据交互。
104.在本实施例中，可以先执行步骤205-步骤208，再执行步骤201-步骤204；也可以先执行步骤201-步骤204，再执行步骤205-步骤208，具体此处不对步骤201-步骤208中的步骤执行顺序进行限制。
105.通过本技术实施例的远程诊断方法，客户端可以通过解析诊断设备通过服务端发送的udp报文，从而获取ip地址，以此就可根据ip地址确定车辆与客户端之间的数据传输通道，同样地，服务端在接收到车辆发送的udp报文之后，也会解析获取到ip地址，然后选择与ip地址对应的数据传输通道将udp报文发送给诊断设备，从而实现车辆与诊断设备之间每一通道传递一个ip地址的数据。
106.下面将针对本技术实施例中的远程诊断方法进行详细描述，请参阅图3，图3为本技术实施例公开的另一种远程诊断方法的交互流程图。包括步骤301-步骤310。
107.301、客户端接收ecu的报文。
108.当客户端中的车辆ecu检测到doip网络连接时，就代表车辆ecu检测到该车辆出现对应的故障信息，然后车辆ecu就会根据该doip网络连接获取到在该doip网络连接中车辆ecu所对应的ip地址。
109.当车辆ecu获取到ip地址后，会将ip地址与车辆故障信息进行打包，然后车辆ecu就会通过udp的形式广播车辆申明的报文，也就是向客户端中的c端发送udp报文。
110.不难理解的是，udp报文中并不包括网络连接状态的信息，但是能收到udp报文，那么网络肯定已经连通了，需要理解的是，本实施例并不对该状态信息所携带的具体内容做限定。
111.此时，客户端中的c端接收到车辆ecu的报文。
112.当然，还需要理解的是，是否存在故障并不会影响车辆ecu或网关广播的udp报文，只要是ecu或者网关存在就会在网络连接后广播的。udp报文只是为了让诊断设备知道车上有哪些设备，不包括诊断数据。诊断数据是在tcp通讯中进行的。
113.此时，车辆ecu或网关发出的udp报文包含：
[0114][0115]
需要说明的是，本报文结构，只罗列出一个报文结构的数据，可根据实际业务逻辑增加或者修改对应结构的数据，本实施例并不对此进行限制。
[0116]
302、客户端获取ecu发送的ip地址、端口号。
[0117]
客户端中的c端接收到udp报文后，会对该udp报文进行解析，就可以知道ecu的ip地址。同时，对应的，也可以获取到车辆ecu的端口号，ecu所发送的udp的端口号。
[0118]
303、如果ip地址为新ip，客户端创建一个新的通道。
[0119]
当c端获取到ip地址后，就会将最新获取到的ip地址与存储在本地存储空间的所有ip地址进行比较，当发现未找到相同的ip地址后，就能够确定该最新获取到的ip地址为
新ip地址，并将该新ip地址存储到本地存储空间。
[0120]
c端就会根据该新ip地址建立一个通道，通道包括一组线程独立的处理本通道的数据，线程包括tcp及udp的收发线程和状态管理线程。可以理解的是，该通道即为上述部分中所描述的第二数据传输通道，即车辆ecu与客户端之间的通讯通道。换言之，c端就可以根据这个新ip地址建立一个tcp的socket连接，并进行通讯。不难理解的，当c端建立tcp连接时，就能够获取到对应的tcp的端口号。
[0121]
可以理解的是，当c端发现该ip地址不是新ip的时候，也就是c端已经根据该ip地址建立一个通道时，不在执行步骤303，而是直接执行步骤304。需要理解的是，当c端发送该ip地址不是新ip的时候，已经创建好的通道即为上述部分中所描述的第一数据传输通道。
[0122]
对应的，为方便理解，对通道数据结构进行说明：
[0123][0124]
需要说明的是，本数据结构，只罗列出一个逻辑通道必须的数据，可根据实际业务逻辑增加或者修改响应的结构部分，本实施例并不对此进行限制。
[0125]
也就是说，在多ip的实现中，c端收到车辆udp报文后，就获取车辆ecu的ip地址，如果是新的ip地址，就在c端创建一个新的通道。
[0126]
304、客户端将通道号和数据打包透传到服务端。
[0127]
当客户端建立起与车辆ecu之间的通讯通道后，可以理解的，该通道即为前述部分中所描述的数据传输通道，该数据传输通道可以为上述部分中所描述的第一数据传输通道或第二数据传输通道，因为在本实施例中，第一数据传输通道或第二数据传输通道均为客户端与车辆ecu之间的数据传输通道，为方便描述，后续不再对此进行赘述。
[0128]
在服务器中的b端与客户端中的c端交互的数据(包括透传的doip数据和状态变化的通知命令)中增加一个字节的通道字段，以标识车辆ecu与客户端之间通讯通道的通道号。该通道字段可以为ip地址，也就是说，根据哪段ip地址建立的通道，就在该通道上增加对应的ip地址。还可以理解的是，本实施例中说明的一个字节的通道字段仅为其中一个具体的实施例，这里可以不限定为一个字节，如果是ip地址，就需要4字节。同时，可以理解到的是，这里不仅可以是一个数字，也可以是ip地址，只要能唯一区分车上的一个ip就可以。为方便描述，后续不再对通道字段的存在形式进行限制。
[0129]
但需要说明的是，为方便描述，本实施例通道字段具体的以ip地址进行举例说明，后续不再对此进行赘述。
[0130]
不难理解的，当b端或c端接收到透传的数据后，就根据通道号将数据交给对应的通道处理。
[0131]
在本实施中，前述步骤301-步骤304可以简单描述为当c端接收到车辆udp报文后，将比较车辆ecu的ip，如果为新的ip地址，将创建一组独立的线程处理本ip的upd及tcp收发，同时将数据加上通道号透传到b端。不难理解的是，透传，在本实施例中指c端或b端将接收到的doip的数据，原样通过云端(云平台)发送到b端或c端。
[0132]
还可以理解的是，本步骤304中所描述的状态变化的通知命令在本实施例中步骤304一般为doip网络已连接的状态通知指令。需要理解的是，本实施例中的状态通知指令主要和远程诊断有关。例如，通知tcp连接建立和断开，通知网络断开等等，使得b、c状态一致。例如b端和诊断仪建立tcp连接，通知c端也和车辆建立连接。例如c端和车辆ecu断开tcp连接后，通知b端断开连接，这样诊断仪就会立即重连。例如c端检测到网络断开，要通知b端，b端要清掉之前保存的车辆的信息，重新接收udp的消息。
[0133]
也就是说，客户端中c端收到车辆的udp报文后，就将udp报文转发到b端。
[0134]
305、服务端接收到透传的udp数据。
[0135]
服务器中的b端接收客户端中的c端透传过来的udp报文，可以理解的是，透传过来的udp报文是通过在图1中所描述的云平台传输的。
[0136]
306、服务端解析数据获取通道号。
[0137]
当服务器中的b端接收到客户端中的c端透传过来的udp报文后，就会对该udp报文进行解析，可以获取到对应的通道字段。
[0138]
当b端获取到通道字段后，就会根据最新获取到的该通道字段搜寻存储在本地存储空间的通道字段。
[0139]
若未找到对应的通道字段，就代表b端与诊断设备之间的通道未建立，执行步骤307。
[0140]
若找到对应的通道字段，就代表b端与诊断设备之间的通道建立成功，执行步骤310。也就是说，当b端需要向c端透传数据时，会根据通道字段找寻到对应的通道，b端通过该通道向c端透传数据。
[0141]
307、如果通道没有创建，服务端创建虚拟网卡。
[0142]
当没有找到对应的通道字段时，就代表b端与诊断设备之间的通道未建立。此时的b端就会根据该最新获取到的通道字段创建一个虚拟网卡，通过该虚拟网卡广播udp报文。可以理解的是，因为在车辆端有多个ecu，而b端物理上只有一个网卡用于doip通讯，所以b
端需要对应每一个车辆的ecu创建一个虚拟网卡。每一个虚拟网卡就是模式一个车上的ecu。换言之，虚拟网卡的ip与ecu的ip存在对应关系。
[0143]
也就是说，b端收到c端转发的udp报文后，如果发现通道字段是一个新的通道，就虚拟出一个网卡，获取ip地址，从而也建立一个通道号相同的新通道。
[0144]
还需要理解的是，b端根据通道字段来判断是否是新的通道。b端创建的虚拟网卡的ip也可以和c端对应的ip不一样，本实施例并不对此进行限制。
[0145]
308、服务端启动dhcp客户端申请ip。
[0146]
当服务端中的b端接收到udp报文的时候，b端就会将车辆声明的报文通过虚拟网卡广播该udp报文给诊断设备。
[0147]
然后，诊断设备收到udp报文后，就会对该udp报文进行解析，从而获取到b端的ip地址以及车辆网关或者是ecu的虚拟地址(一般是一个16位的id)。也就是说，诊断设备可以通过udp报文获取车辆ecu或者网关的ip地址或虚拟地址等。
[0148]
诊断设备收到udp报文后，就会和这个虚拟网卡对应的ip建立tcp的socket连接。当诊断设备建立起新的tcp的socket的连接后，服务端就会启动动态主机配置协议(dhcp，dynamic host configurationprotocol)客户端申请ip。不难理解的，如果dhcp客户端没有获取ip，就启动autoip自动获取ip。
[0149]
需要理解的是，dhcp是一个局域网的网络协议。主要有两个用途:
[0150]
1、给内部网络或网络服务供应商自动分配ip地址。
[0151]
2、给用户或者内部网络管理员作为对所有计算机作中央管理的手段。
[0152]
还需要理解的是，诊断设备中运行有dhcp服务进程，而服务端中运行的dhcp客户端可以使得诊断设备运行dhcp服务进程，从而申请ip。
[0153]
还需要理解的是，本实施例并不对dhcp的用途进行限制，dhcp还可以具备其他功能。
[0154]
309、服务端创建通道。
[0155]
服务端中的b端与诊断设备建立tcp的socket连接后，就会根据由dhcp客户端获取到的ip地址及socket连接请求创建通道，可以理解的是，该通道就是上述部分中所描述的第二数据传输通道或第三数据传输通道。需要理解的是，若ip地址为新增ip地址，则可以理解为第二数据传输通道；若ip地址不是新增ip地址，则可以理解为第三数据传输通道。同时，也会在服务端中b端与诊断设备交互的数据中增加一个字节的通道字段，以标识通道号。
[0156]
可以理解的是，服务端创建通道后，例如车辆上有三个ip分别为192.168.100.1，192.168.100.2，或192.168.100.3。这时c端收到这三个ip的udp报文后，首次收到时就会创建通道号为1、2、3的三个通道。
[0157]
在b端首次收到c端转发的这三个ip的udp数据时，就会发现有新的通道，就会创建虚拟网卡，申请地址。假设收到通道1时，创建的网卡为192.168.1.100；收到通道2时，创建的网卡为192.168.1.101；收到通道3时，创建的网卡为192.168.1.102。
[0158]
那在后面的通信中，当b端通过192.168.1.102接收到的数据，就知道是通道3的，转发到c端，c端看到是通道3，就知道把这个数据发给车辆上192.168.100.3。同样的c端收到192.168.100.3的数据，就知道是通道3的，转发给b端后，b端就会通过192.168.1.102这
个ip发送给诊断设备。
[0159]
也就是说，虚拟网卡发送的通道字段和c端新增的通道字段是一致的。也可以理解为，c端连接车辆ecu的ip和b端虚拟网卡的ip是一一对应的。根据哪个ip获取的数据，就可以知道是对应的通道。
[0160]
310、服务端向客户端发送诊断数据。
[0161]
需要理解的是，诊断设备收到udp报文后，获取到服务端中b端的ip地址，并对udp报文进行解析，从而获取车辆网关或ecu的的虚拟地址(一般就是一个16位的id)。
[0162]
然后诊断设备就会与b端建立tcp连接。当tcp连接建立后，b端就会向c端发送状态通知指令，此时的状态通知指令是通知c端与车辆ecu建立tcp连接。然后诊断设备通过tcp向车辆发送路由激活命令，车辆返回路由激活应答。此时，诊断设备就可以和车辆ecu通过tcp通讯，进行诊断数据的交互。
[0163]
还需要理解的是，本实施例中的状态通知指令主要和远程诊断有关。例如，通知tcp连接建立和断开，通知网络断开等等，使得b、c状态一致。例如b端和诊断仪建立tcp连接，通知c端也和车辆建立连接。例如c端和车辆ecu断开tcp连接后，通知b端断开连接，这样诊断仪就会立即重连。例如c端检测到网络断开，要通知b端，b端要清掉之前保存的车辆的信息，重新接收udp的消息。
[0164]
于此同时，还有与客户端通道对应的通道标识。但是该通道标识并不是通过tcp连接发送的。b端根据通道号将数据交给对应的通道处理。由此b端将对应的诊断数据发送给客户端中的c端。
[0165]
由此可见，本方法在软件层面上，为每一个ip地址建立一个通道，通道包括一组线程独立的处理本通道的数据，线程包括tcp或udp的收发线程和状态管理线程。每一个通道都可以独立地完成ecu和诊断设备之间的数据转发，从而实现多ip同时通讯。在b端与c端交互的数据(包括透传的doip数据和状态变化的通知命令)中增加一个字节的通道字段，标识通道号，b端和c端接收到透传的数据后，就根据通道号将数据交给对应的通道处理。c端接收到车辆udp报文后，将比较发送方的ip，如果为新的ip地址，将创建一组独立的线程处理本ip的upd或tcp收发，同时将数据加上通道号透传到b端，b端收到透传的udp数据后，如果对应的通道不存在，则创建一个虚拟网卡，创建对应的通道。从而在b端与c端之间建立多个虚拟的通道，实现诊断设备和车辆ecu之间，多个ip并行的通讯。
[0166]
应该理解的是，虽然如上所述的各实施例所涉及的流程图中的各个步骤按照箭头的指示依次显示，但是这些步骤并不是必然按照箭头指示的顺序依次执行。除非本文中有明确的说明，这些步骤的执行并没有严格的顺序限制，这些步骤可以以其它的顺序执行。而且，如上所述的各实施例所涉及的流程图中的至少一部分步骤可以包括多个步骤或者多个阶段，这些步骤或者阶段并不必然是在同一时刻执行完成，而是可以在不同的时刻执行，这些步骤或者阶段的执行顺序也不必然是依次进行，而是可以与其它步骤或者其它步骤中的步骤或者阶段的至少一部分轮流或者交替地执行。
[0167]
若方案涉及敏感信息(如用户信息、企业信息)，则应当说明针对敏感信息的收集、使用和处理需要遵守相关国家和地区的法律法规和标准，且需要在相应主体(如用户或企业等)许可或同意的情况下进行。
[0168]
本实施例提供了一种远程诊断方法，可以解析诊断设备通过服务端向客户端发送
的udp报文，从而获取ip地址，以此就可根据ip地址确定车辆与客户端之间的数据传输通道。与此同时，客户端每发现一个新的ip地址，客户端与车辆之间就会有一组新的数据传输通道，从而实现车辆与诊断设备之间每一通道传递一个ip地址的数据，不同的通道互不影响。
[0169]
对应的，客户端每发现一个新的ip地址，客户端与车辆之间就会有一组新的通道，同时在服务端会为每一个新通道创建一个虚拟网卡，通过该虚拟网卡创建对应的服务端与诊断设备之间的通道。每一组通道独立处理一个ip的数据通讯，不同的通道互不影响。由此，支持了多ip的doip诊断。
[0170]
上面对本技术实施例中的一种远程诊断方法进行了描述，下面对本技术实施例中的一种远程诊断装置的结构进行描述，请参阅图4，一种远程诊断装置的结构，应用于客户端，包括：
[0171]
获取单元401，用于获取诊断设备通过服务端发送的第一udp报文；
[0172]
解析单元402，用于解析第一udp报文，以获取对应的第一ip地址；
[0173]
确定单元403，用于根据第一ip地址确定对应的第一数据传输通道；
[0174]
发送单元404，用于通过第一数据传输通道将第一udp报文发送至车辆上与第一ip地址对应的电子控制单元。
[0175]
示例性地，装置还包括：创建单元405。
[0176]
获取单元401，还用于获取车辆广播的第二udp报文；
[0177]
解析单元402，还用于解析第二udp报文，以获取对应的第二ip地址；
[0178]
创建单元405，用于当第二ip地址为新增ip地址时，则与第二ip地址对应的电子控制单元之间创建第二数据传输通道。
[0179]
示例性地，
[0180]
发送单元404，还用于将第二udp报文以及对应的第二数据传输通道的标识号发送至服务端。
[0181]
示例性地，装置还包括检测单元406。
[0182]
检测单元406，用于检测与车辆的网络诊断协议doip的网络是否连接，若是，执行获取车辆广播的第二udp报文的步骤。
[0183]
下面对本技术实施例中的另一种远程诊断装置的结构进行描述，请参阅图5，另一种基于远程诊断装置的结构，应用于服务端，包括：
[0184]
获取单元501，用于获取车辆通过客户端发送的第三用户数据报协议udp报文；
[0185]
解析单元502，用于解析第三udp报文，以获取对应的第三ip地址；
[0186]
确定单元503，用于根据第三ip地址确定对应的第三数据传输通道；
[0187]
发送单元504，用于将第三udp报文通过第三数据传输通道发送至诊断设备，以实现车辆和诊断设备的数据交互。
[0188]
示例性地，装置还包括：接收单元505及创建单元506。
[0189]
接收单元505，用于接收客户端发送的第二udp报文以及标识号；
[0190]
创建单元506，用于当目标标识号为新增标识号时，则与诊断设备之间创建与新增标识号对应的第二数据传输通道。
[0191]
示例性地，装置还包括广播单元507及建立单元508。
[0192]
创建单元506，具体用于创建虚拟网卡；
[0193]
广播单元507，用于通过虚拟网卡广播第二udp报文；
[0194]
接收单元505，具体用于接收诊断设备基于第二udp报文携带的第二ip地址发送的socket连接请求；
[0195]
建立单元508，用于基于socket连接请求建立与诊断设备之间的第二数据传输通道。
[0196]
下面请参阅图6，本技术实施例公开的一种远程诊断设备包括：
[0197]
中央处理器601，存储器605，输入输出接口604，有线或无线网络接口603以及电源602；
[0198]
存储器605为短暂存储存储器或持久存储存储器；
[0199]
中央处理器601配置为与存储器605通信，并执行存储器605中的指令操作以执行前述图2或图3所示实施例中的方法。
[0200]
本技术实施例还提供一种芯片系统，其特征在于，芯片系统包括至少一个处理器和通信接口，通信接口和至少一个处理器通过线路互联，至少一个处理器用于运行计算机程序或指令，以执行前述图2或图3所示实施例中的方法。
[0201]
所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统，装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。
[0202]
在本技术所提供的几个实施例中，应该理解到，所揭露的系统，装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。
[0203]
所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
[0204]
另外，在本技术各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。
[0205]
所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本技术的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本技术各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：u盘、移动硬盘、只读存储器(rom，read-only memory)、随机存取存储器(ram，random access memory)、磁碟或者光盘等各种可以存储程序代码的介质。