一种故障诊断方法、装置、车载终端及介质与流程

文档序号:26588108发布日期:2021-09-10 19:58阅读:59来源:国知局
一种故障诊断方法、装置、车载终端及介质与流程

1.本技术涉及汽车技术领域,尤其涉及一种故障诊断方法、装置、车载终端及介质。


背景技术:

2.汽车故障诊断是在不解体或卸下个别零件的条件下,确定汽车状况并查明故障部位及原因的技术,包括汽车发动机的检测与诊断、汽车底盘的检测与诊断、汽车车身及零部件的检测与诊断、汽车排气和噪声的检测与诊断以及汽车车机系统的检测与诊断等。
3.目前,通常是利用诊断仪等外部设备进行汽车故障诊断,这不仅会占用车载终端的大量通信资源来维护与诊断仪等外部设备的通信连接,还会增加汽车故障诊断的硬件成本。


技术实现要素:

4.本技术实施例提供了一种故障诊断方法、装置、车载终端及介质,用以解决现有技术存在的汽车故障诊断成本较高、通信资源占用较多的问题。
5.本技术实施例提供的技术方案如下:
6.一方面,本技术实施例提供了一种应用于车载终端中的诊断客户端的故障诊断方法,包括:
7.获取通过调用目标诊断服务的应用程序接口(application programming interface,api)输入的目标诊断服务的诊断服务数据;
8.将诊断服务数据封装成符合统一诊断服务(unified diagnostic services,uds)协议和基于以太网的诊断技术(diagnostic communication over internet protocol,doip)协议的诊断服务请求报文并发送至诊断服务器;
9.接收诊断服务器基于诊断服务请求报文返回的诊断服务响应报文;其中,诊断服务响应报文是,诊断服务器基于诊断服务请求报文中的诊断服务数据获得故障诊断数据,并对故障诊断数据进行封装后获得的;
10.对诊断服务响应报文进行解析,得到故障诊断数据,并基于故障诊断数据,确定目标诊断服务的故障诊断结果。
11.在一种可能的实施方式中,获取通过调用目标诊断服务的api输入的目标诊断服务的诊断服务数据,包括:
12.响应于针对目标诊断服务的api执行的调用操作,显示命令窗口;
13.基于在命令窗口中执行的用户操作,获取目标诊断服务的诊断服务数据。
14.在一种可能的实施方式中,基于在命令窗口中执行的用户操作,获取目标诊断服务的诊断服务数据,包括:
15.获取在命令窗口中的命令输入框内输入的数据作为目标诊断服务的诊断服务数据;
16.和/或,获取在命令窗口中的命令选择框内选择的数据作为目标诊断服务的诊断
服务数据。
17.在一种可能的实施方式中,将诊断服务数据封装成符合uds协议和doip协议的诊断服务请求报文之前,还包括:
18.将诊断服务数据解析为uds协议支持的数据格式。
19.在一种可能的实施方式中,将诊断服务数据封装成符合uds协议和doip协议的诊断服务请求报文之前,还包括:
20.对诊断服务数据进行数据校验,并确定诊断服务数据的数据校验通过。
21.在一种可能的实施方式中,将诊断服务数据封装成符合uds协议和doip协议的诊断服务请求报文,包括:
22.将诊断服务数据封装成符合uds协议的应用层报文后再封装成符合doip协议的通信层报文,得到诊断服务请求报文。
23.另一方面,本技术实施例提供了一种应用于车载终端中的诊断客户端的故障诊断装置,包括:
24.数据获取单元,用于获取通过调用目标诊断服务的api输入的目标诊断服务的诊断服务数据;
25.封装发送单元,用于将诊断服务数据封装成符合uds协议和doip协议的诊断服务请求报文并发送至诊断服务器;
26.报文接收单元,用于接收诊断服务器基于诊断服务请求报文返回的诊断服务响应报文;其中,诊断服务响应报文是,诊断服务器基于诊断服务请求报文中的诊断服务数据获得故障诊断数据,并对故障诊断数据进行封装后获得的;
27.报文解析单元,用于对诊断服务响应报文进行解析,得到故障诊断数据,并基于故障诊断数据,确定目标诊断服务的故障诊断结果。
28.在一种可能的实施方式中,获取通过调用目标诊断服务的api输入的目标诊断服务的诊断服务数据时,数据获取单元具体用于:
29.响应于针对目标诊断服务的api执行的调用操作,显示命令窗口;
30.基于在命令窗口中执行的用户操作,获取目标诊断服务的诊断服务数据。
31.在一种可能的实施方式中,基于在命令窗口中执行的用户操作,获取目标诊断服务的诊断服务数据时,数据获取单元具体用于:
32.获取在命令窗口中的命令输入框内输入的数据作为目标诊断服务的诊断服务数据;
33.和/或,获取在命令窗口中的命令选择框内选择的数据作为目标诊断服务的诊断服务数据。
34.在一种可能的实施方式中,本技术实施例提供的故障诊断装置还包括:
35.数据解析单元,用于将诊断服务数据解析为uds协议支持的数据格式。
36.在一种可能的实施方式中,本技术实施例提供的故障诊断装置还包括:
37.数据检查单元,用于对诊断服务数据进行数据校验,并确定诊断服务数据的数据校验通过。
38.在一种可能的实施方式中,将诊断服务数据封装成符合uds协议和doip协议的诊断服务请求报文时,封装发送单元具体用于:
39.将诊断服务数据封装成符合uds协议的应用层报文后再封装成符合doip协议的通信层报文,得到诊断服务请求报文。
40.另一方面,本技术实施例提供了一种车载终端,包括:存储器、处理器和存储在存储器上并可在处理器上运行的计算机程序,处理器执行计算机程序时实现本技术实施例提供的故障诊断方法。
41.另一方面,本技术实施例还提供了一种计算机可读存储介质,计算机可读存储介质存储有计算机指令,计算机指令被处理器执行时实现本技术实施例提供的故障诊断方法。
42.本技术实施例的有益效果如下:
43.本技术实施例中,通过在车载终端中安装诊断客户端,利用诊断客户端与诊断服务器的信令交互即可实现汽车故障诊断,无需车载终端外接诊断仪等外部设备,从而可以减少汽车故障诊断的硬件成本,节省车载终端为维护与诊断仪等外部设备的通信连接所使用的通信资源。
44.本技术的其它特征和优点将在随后的说明书中阐述,并且,部分地可以从说明书中变得显而易见,或者通过实施本技术而了解。本技术的目的和其他优点可通过在所写的说明书、权利要求书、以及附图中特别指出的结构来实现和获得。
附图说明
45.此处所说明的附图用来提供对本技术的进一步理解,构成本技术的一部分,本技术的示意性实施例及其说明用于解释本技术,并不构成对本技术的不当限定。在附图中:
46.图1a为本技术实施例中包含命令输入框的命令窗口示意图;
47.图1b为本技术实施例中包含命令选择框的命令窗口示意图;
48.图1c为本技术实施例中包含命令输入框和命令选择框的命令窗口示意图;
49.图2a为本技术实施例中传统故障诊断系统框架示意图;
50.图2b为本技术实施例中故障诊断系统框架示意图;
51.图3为本技术实施例中故障诊断方法的概况流程示意图;
52.图4为本技术实施例中故障诊断方法的具体流程示意图;
53.图5为本技术实施例中故障诊断装置的功能结构示意图;
54.图6为本技术实施例中车载终端的硬件结构示意图。
具体实施方式
55.为了使本技术的目的、技术方案及有益效果更加清楚明白,下面将结合本技术实施例中的附图,对本技术实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例仅仅是本技术一部分实施例,并不是全部的实施例。基于本技术中的实施例,本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例,都属于本技术保护的范围。
56.为便于本领域技术人员更好地理解本技术,下面先对本技术涉及的技术用语进行简单介绍。
57.1、车载终端,为可以安装在汽车上并具备定位、通信、行车记录、电话呼叫、语音播
报、音视频播放、安防报警、远程安全断油、断电安全保护等功能,且预留有多个rs

232接口和rs485接口,可外接计价器、摄像头、麦克风、耳机等的前端设备。
58.2、诊断客户端,为可以安装在车载终端、计算机、手机等终端设备上,向用户提供汽车故障诊断服务并支持用户互动的应用程序。本技术仅以诊断客户端安装在车载终端上为例进行说明。
59.3、诊断服务器,为向诊断客户端提供诊断测试服务、数据库服务、计算服务等各类服务的后台运行设备。
60.4、api,为诊断客户端向用户提供的用于输入诊断服务数据的接口。本技术中,诊断客户端针对各个诊断服务分别提供有相应的api。
61.5、命令窗口,为诊断客户端向用户显示的用于输入诊断服务的诊断服务数据的窗口。本技术中,命令窗口上显示有命令输入框和命令选择框中的至少一个,例如,参阅图1a所示,命令窗口可以只包含命令输入框,又如,参阅图1b所示,命令窗口还可以只包含命令选择框,再如,参阅图1c所示,命令窗口还可以包含命令输入框和命令选择框。
62.需要说明的是,本技术中提及的“和/或”,描述的是关联对象的关联关系,表示可以存在三种关系,例如,a和/或b,可以表示:单独存在a,同时存在a和b,单独存在b这三种情况。字符“/”一般表示前后关联对象是一种“或”的关系。
63.在介绍了本技术涉及的技术用语后,接下来,对本技术实施例的应用场景和设计思想进行简单介绍。
64.目前,参阅图2a所示,汽车故障诊断通常是利用诊断仪等外部设备来实现,这不仅会占用车载终端的大量通信资源来维护与诊断仪等外部设备的通信连接,还会增加汽车故障诊断的硬件成本。
65.为此,本技术实施例中,参阅图2b所示,汽车的车载终端上安装有诊断客户端110,安装在汽车的车载终端上的诊断客户端110通过通信网络与诊断服务器120进行通信连接。实际应用中,用户可以通过调用诊断客户端110提供的目标诊断服务的api输入目标诊断服务的诊断服务数据;诊断客户端110获取到用户通过调用目标诊断服务的api输入的目标诊断服务的诊断服务数据后,将该诊断服务数据封装成符合uds协议和doip协议的诊断服务请求报文并发送至诊断服务器120;诊断服务器120接收到诊断客户端110发送的诊断服务请求报文后,对该诊断服务请求报文进行解析,得到诊断服务数据,并基于诊断服务数据获得故障诊断数据后,将该故障诊断数据封装成符合uds协议和doip协议的诊断服务响应报文并返回至诊断客户端110;诊断客户端110接收到诊断服务器120返回的诊断服务响应报文后,对该诊断服务响应报文进行解析,得到故障诊断数据,基于该故障诊断数据,确定目标诊断服务的故障诊断结果并显示给用户。
66.这样,通过在车载终端中安装诊断客户端110,利用诊断客户端110与诊断服务器120的信令交互即可实现汽车故障诊断,无需车载终端外接诊断仪等外部设备,从而可以减少汽车故障诊断的硬件成本,节省车载终端为维护与诊断仪等外部设备的通信连接所使用的通信资源。
67.在介绍了本技术实施例的应用场景和设计思想之后,下面对本技术实施例提供的技术方案进行详细说明。
68.本技术实施例提供了一种应用于车载终端中的诊断客户端110的故障诊断方法,
参阅图3所示,本技术实施例提供的故障诊断方法的概况流程如下:
69.步骤301:诊断客户端110获取通过调用目标诊断服务的api输入的该目标诊断服务的诊断服务数据。
70.实际应用中,诊断客户端110针对各个诊断服务分别提供有相应的api,用户可以通过调用该目标诊断服务的api输入的该目标诊断服务的诊断服务数据。具体的,诊断客户端110监测到用户针对该目标诊断服务的api执行了调用操作时,响应于针对该目标诊断服务的api执行的调用操作,显示命令窗口,并基于在该命令窗口中执行的用户操作,获取该目标诊断服务的诊断服务数据。
71.例如:假设命令窗口是如图1a所示的只包含命令输入框的命令窗口,则诊断客户端110监测到用户针对该目标诊断服务的api执行的调用操作时,响应于针对该目标诊断服务的api执行的调用操作,显示如图1a所示的命令窗口,并获取在该命令窗口中的命令输入框内输入的数据作为该目标诊断服务的诊断服务数据。
72.又如:假设命令窗口是如图1b所示的只包含命令选择框的命令窗口,则诊断客户端110监测到用户针对该目标诊断服务的api执行的调用操作时,响应于针对该目标诊断服务的api执行的调用操作,显示如图1b所示的命令窗口,并获取在该命令窗口中的命令选择框内选择的数据作为该目标诊断服务的诊断服务数据。
73.再如:假设命令窗口是如图1c所示的包含命令输入选择框和命令选择框的命令窗口,则诊断客户端110监测到用户针对该目标诊断服务的api执行的调用操作时,响应于针对该目标诊断服务的api执行的调用操作,显示如图1c所示的命令窗口,并获取在该命令窗口中的命令输入框内输入的数据以及在该命令窗口中的命令选择框内选择的数据作为该目标诊断服务的诊断服务数据。
74.步骤302:诊断客户端110将该诊断服务数据封装成符合uds协议和doip协议的诊断服务请求报文并发送至诊断服务器120。
75.实际应用中,诊断客户端110获取到该目标诊断服务的诊断服务数据之前,将该诊断服务数据封装成符合uds协议和doip协议的诊断服务请求报文之前,还可以先将该诊断服务数据解析为uds协议支持的数据格式,并对该诊断服务数据进行数据校验。
76.在具体实施时,诊断客户端110可以对该诊断服务数据进行必填校验、规范性校验和合法性校验等各项数据校验,确定该诊断服务数据的必填校验、规范性校验和合法性校验等各项数据校验均通过后,再将该诊断服务数据封装成符合uds协议和doip协议的诊断服务请求报文并发送至诊断服务器120。具体的,诊断客户端110可以将该诊断服务数据封装成符合uds协议的应用层报文后再封装成符合doip协议的通信层报文,从而得到诊断服务请求报文,并将该诊断服务请求报文发送至诊断服务器120。
77.步骤303:诊断客户端110接收诊断服务器120基于该诊断服务请求报文返回的诊断服务响应报文,对该诊断服务响应报文进行解析,得到故障诊断数据后,基于该故障诊断数据,确定该目标诊断服务的故障诊断结果。
78.实际应用中,诊断服务器120接收到诊断客户端110发送的诊断服务请求报文后,可以对该诊断服务请求报文进行解析,得到诊断服务数据,基于该诊断服务数据获得故障诊断数据后,可以将该故障诊断数据封装成符合uds协议和doip协议的诊断服务响应报文并返回至诊断客户端110。具体的,诊断服务器120可以将该故障诊断数据封装成符合uds协
议的应用层报文后再封装成符合doip协议的通信层报文,从而得到诊断服务响应报文,并将该诊断服务响应报文返回至诊断客户端110。
79.进一步的,诊断客户端110接收到诊断服务器120返回的诊断服务响应报文后,可以对该诊断服务响应报文进行解析,得到故障诊断数据,并基于该述故障诊断数据,确定该目标诊断服务的故障诊断结果,以及向用户显示该目标诊断服务的故障诊断结果。
80.下面对本技术实施例提供的故障诊断方法作进一步详细说明,参阅图4所示,本技术实施例提供的故障诊断方法的具体流程如下:
81.步骤401:诊断客户端110监测到用户针对目标诊断服务的api执行了调用操作时,响应于用户针对该目标诊断服务的api执行的调用操作,显示命令窗口。
82.步骤402:诊断客户端110基于用户在该命令窗口中执行的用户操作,获取该目标诊断服务的诊断服务数据。
83.步骤403:诊断客户端110将该诊断服务数据解析为uds协议支持的数据格式,并对该诊断服务数据进行必填校验、规范性校验和合法性校验等各项数据校验。
84.步骤404:诊断客户端110确定该诊断服务数据的必填校验、规范性校验和合法性校验等各项数据校验均通过后,将该诊断服务数据封装成符合uds协议和doip协议的诊断服务请求报文。
85.步骤405:诊断客户端110将该诊断服务请求报文发送至诊断服务器120。
86.步骤406:诊断服务器120接收到诊断客户端110发送的诊断服务请求报文后,对该诊断服务请求报文进行解析,得到诊断服务数据。
87.步骤407:诊断服务器120基于该诊断服务数据获得故障诊断数据后,将该故障诊断数据封装成符合uds协议和doip协议的诊断服务响应报文。
88.步骤408:诊断服务器120将该诊断服务响应报文返回至诊断客户端110。
89.步骤409:诊断客户端110接收到诊断服务器120返回的诊断服务响应报文后,对该诊断服务响应报文进行解析,得到故障诊断数据。
90.步骤410:诊断客户端110基于该述故障诊断数据,确定该目标诊断服务的故障诊断结果并显示。
91.基于上述实施例,本技术实施例提供了一种应用于车载终端中的诊断客户端110的故障诊断装置,参阅图5所示,本技术实施例提供的故障诊断装置500至少包括:
92.数据获取单元501,用于获取通过调用目标诊断服务的api输入的目标诊断服务的诊断服务数据;
93.封装发送单元502,用于将诊断服务数据封装成符合uds协议和doip协议的诊断服务请求报文并发送至诊断服务器;
94.报文接收单元503,用于接收诊断服务器基于诊断服务请求报文返回的诊断服务响应报文;其中,诊断服务响应报文是,诊断服务器基于诊断服务请求报文中的诊断服务数据获得故障诊断数据,并对故障诊断数据进行封装后获得的;
95.报文解析单元504,用于对诊断服务响应报文进行解析,得到故障诊断数据,并基于故障诊断数据,确定目标诊断服务的故障诊断结果。
96.在一种可能的实施方式中,获取通过调用目标诊断服务的api输入的目标诊断服务的诊断服务数据时,数据获取单元501具体用于:
network,lan),广域网(wide area network,wan)和/或公共网络,例如因特网)通信。如图6所示,网络适配器606通过总线603与车载终端600的其它模块通信。应当理解,尽管图6中未示出,可以结合车载终端600使用其它硬件和/或软件模块,包括但不限于:微代码、设备驱动器、冗余处理器、外部磁盘驱动阵列、磁盘阵列(redundant arrays of independent disks,raid)子系统、磁带驱动器以及数据备份存储子系统等。
115.需要说明的是,图6所示的车载终端600仅仅是一个示例,并不构成对车载终端600的限定,车载终端600可以包括比图示更多或更少的组件。
116.下面对本技术实施例提供的计算机可读存储介质进行介绍。本技术实施例提供的计算机可读存储介质存储有计算机指令,计算机指令被处理器执行时实现本技术实施例提供的故障诊断方法。具体地,该可执行程序可以固件的形式内置在车载终端600中,也可以诊断客户端110的形式安装在车载终端600中,这样,车载终端600就可以通过执行内置或者安装的可执行程序实现本技术实施例提供的故障诊断方法。
117.此外,本技术实施例提供的故障诊断方法还可以实现为一种程序产品,该程序产品包括程序代码,当该程序产品可以在车载终端600上运行时,该程序代码用于使车载终端600执行本技术实施例提供的故障诊断方法。
118.本技术实施例提供的程序产品可以采用一个或多个可读介质的任意组合,其中,可读介质可以是可读信号介质或者可读存储介质,而可读存储介质可以是但不限于是电、磁、光、电磁、红外线、或半导体的系统、装置或器件,或者任意以上的组合,具体地,可读存储介质的更具体的例子(非穷举的列表)包括:具有一个或多个导线的电连接、便携式盘、硬盘、ram、rom、可擦式可编程只读存储器(erasable programmable read only memory,eprom)、光纤、便携式紧凑盘只读存储器(compact disc read

only memory,cd

rom)、光存储器件、磁存储器件、或者上述的任意合适的组合。
119.本技术实施例提供的程序产品可以采用cd

rom并包括程序代码,还可以在计算设备上运行。然而,本技术实施例提供的程序产品不限于此,在本技术实施例中,可读存储介质可以是任何包含或存储程序的有形介质,该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。
120.应当注意,尽管在上文详细描述中提及了装置的若干单元或子单元,但是这种划分仅仅是示例性的并非强制性的。实际上,根据本技术的实施方式,上文描述的两个或更多单元的特征和功能可以在一个单元中具体化。反之,上文描述的一个单元的特征和功能可以进一步划分为由多个单元来具体化。
121.此外,尽管在附图中以特定顺序描述了本技术方法的操作,但是,这并非要求或者暗示必须按照该特定顺序来执行这些操作,或是必须执行全部所示的操作才能实现期望的结果。附加地或备选地,可以省略某些步骤,将多个步骤合并为一个步骤执行,和/或将一个步骤分解为多个步骤执行。
122.尽管已描述了本技术的优选实施例,但本领域内的技术人员一旦得知了基本创造性概念,则可对这些实施例作出另外的变更和修改。所以,所附权利要求意欲解释为包括优选实施例以及落入本技术范围的所有变更和修改。
123.显然,本领域的技术人员可以对本技术实施例进行各种改动和变型而不脱离本技术实施例的精神和范围。这样,倘若本技术实施例的这些修改和变型属于本技术权利要求
及其等同技术的范围之内,则本技术也意图包含这些改动和变型在内。
当前第1页1 2 
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1