掌桥专利:专业的专利平台
掌桥专利
首页

故障码库的访问控制方法、装置、电子设备及存储介质

文献发布时间:2023-06-19 13:45:04


故障码库的访问控制方法、装置、电子设备及存储介质

技术领域

本申请属于汽车电子技术领域,尤其涉及一种故障码库的访问控制方法、装置、电子设备及存储介质。

背景技术

目前,故障码库放置于服务器中。用户设备需要通过访问服务器获取故障码对相应的故障信息。为了提供稳定的故障码信息服务,需要防止对故障码库的恶意访问。

发明内容

本申请实施例提供了一种故障码库的访问控制方法、装置、电子设备及存储介质,可以解决对故障码库的恶意访问的问题。

第一方面,本申请实施例提供了一种故障码库的访问控制方法,包括:

接收用户设备发送的故障码库访问请求,所述故障码库访问请求携带所述用户设备的标识信息;

根据所述标识信息确定所述用户设备的故障码库访问频次信息;

基于所述用户设备的故障码库访问频次信息,确定所述用户设备的故障码库访问请求是否存在异常;

在所述用户设备的故障码库访问请求存在异常时,对所述用户设备作出异常访问请求响应。

基于本申请实施例的第一方面,在第一种可能的实现方式中,所述对所述用户设备作出异常访问请求响应,包括:

拒绝所述用户设备对所述故障码库的访问。

基于本申请实施例的第一方面,在第二种可能的实现方式中,所述故障码库访问频次信息包括:所述用户设备当前发送的所述故障码库访问请求与上一次发送的故障码库访问请求之间的发送时间间隔;

所述基于所述用户设备的故障码库访问频次信息,确定所述用户设备的故障码库访问请求是否存在异常,包括:

获取上一次发送的故障码库访问请求对应的检测模式;

根据所述检测模式确定对应的检测时长;

若所述用户设备当前发送的所述故障码库访问请求与上一次发送的所述故障码库访问请求之间的发送时间间隔小于所述检测模式对应的检测时长,则确定所述用户设备的故障码库访问请求存在异常。

基于本申请实施例的第一方面,在第三种可能的实现方式中,所述检测模式包括:单ECU检测模式和全车检测模式。

基于本申请实施例的第一方面,在第四种可能的实现方式中,所述根据所述检测模式确定对应的检测时长包括:

将所述检测模式下,所述用户设备读取故障码的最短时长,确定为所述检测模式对应的检测时长。

基于本申请实施例的第一方面,在第五种可能的实现方式中,所述根据所述标识信息确定所述用户设备的故障码库访问频次信息,包括:

获取所述用户设备发送所述故障码库访问请求的时刻对应的访问时间段;以及,

获取所述用户设备在所述访问时间段内发送所述故障码库访问请求的总次数;

所述基于所述用户设备的故障码库访问频次信息,确定所述用户设备的故障码库访问请求是否存在异常,包括:

若所述总次数大于所述访问时间段对应的预设次数,则确定所述用户设备的故障码库访问请求存在异常。

基于本申请实施例的第一方面,在第六种可能的实现方式中,所述访问控制方法还包括:

获取所述用户设备在所述预设访问时间段发送所述故障码库访问请求的概率;

基于所述概率确定所述访问时间段对应的预设次数。

第二方面,本申请实施例提供了一种故障码库的访问控制装置,包括:

故障码库访问请求接收模块,用于接收用户设备发送的故障码库访问请求,所述故障码库访问请求携带所述用户设备的标识信息;

故障码库访问频次信息确定模块,用于根据所述标识信息确定所述用户设备的故障码库访问频次信息;

故障码库访问请求异常确定模块,用于基于所述用户设备的故障码库访问频次信息,确定所述用户设备的故障码库访问请求是否存在异常;

异常访问请求响应模块,用于在所述用户设备的故障码库访问请求存在异常时,对所述用户设备作出异常访问请求响应。

基于本申请实施例的第二方面,在第一种可能的实现方式中,所述异常访问请求响应模块,还用于拒绝所述用户设备对所述故障码库的访问。

基于本申请实施例的第二方面,在第二种可能的实现方式中,所述故障码库访问频次信息包括:所述用户设备当前发送的所述故障码库访问请求与上一次发送的故障码库访问请求之间的发送时间间隔;

所述故障码库访问请求异常确定模块包括:

检测模式获取模块,用于获取上一次发送的故障码库访问请求对应的检测模式;

检测时长确定模块,用于根据所述检测模式确定对应的检测时长;

时间间隔判断模块,用于若所述用户设备当前发送的所述故障码库访问请求与上一次发送的所述故障码库访问请求之间的发送时间间隔小于所述检测模式对应的检测时长,则确定所述用户设备的故障码库访问请求存在异常。

基于本申请实施例的第二方面,在第三种可能的实现方式中,所述检测模式包括:单ECU检测模式和全车检测模式。

基于本申请实施例的第二方面,在第四种可能的实现方式中,所述检测时长确定模块包括:

最短时长确定模块,用于将所述检测模式下,所述用户设备读取故障码的最短时长,确定为所述检测模式对应的检测时长。

基于本申请实施例的第二方面,在第五种可能的实现方式中,故障码库访问频次信息确定模块包括:

访问请求总次数获取模块,用于获取所述用户设备发送所述故障码库访问请求的时刻对应的访问时间段;以及,获取所述用户设备在所述访问时间段内发送所述故障码库访问请求的总次数;

所述故障码库访问请求异常确定模块包括:

总次数判断模块,用于若所述总次数大于所述访问时间段对应的预设次数,则确定所述用户设备的故障码库访问请求存在异常。

基于本申请实施例的第二方面,在第六种可能的实现方式中,所述访问控制装置还包括:

访问请求概率获取模块,用于获取所述用户设备在所述预设访问时间段发送所述故障码库访问请求的概率;

预设次数确定模块,用于基于所述概率确定所述访问时间段对应的预设次数。

第三方面,本申请实施例提供了一种电子设备,包括:

存储器、处理器以及存储在所述存储器中并可在所述处理器上运行的计算机程序,所述计算机程序被所述处理器执行时实现上述第一方面或其任意一种实现方式中所述的故障码库的访问控制方法的步骤。

第四方面,本申请实施例提供了一种计算机可读存储介质,包括:所述计算机可读存储介质存储有计算机程序,所述计算机程序被处理器执行时实现上述第一方面或其任意一种实现方式中所述的故障码库的访问控制方法的步骤。

第五方面,本申请实施例提供了一种计算机程序产品,当计算机程序产品在电子设备上运行时,使得电子设备执行上述第一方面或其任意一种实现方式中所述的故障码库的访问控制方法的步骤。

根据本申请实施例提供的一种故障码库的访问控制方法及装置,通过根据用户设备发送的故障码库访问请求中的用户设备标识,确定的访问频次信息,并通过该访问频次信息确定故障码库访问请求是否存在异常,可以发现和避免过于频繁的异常访问,从而解决对故障码库的恶意访问的问题。

附图说明

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

图1是本申请一实施例提供的故障码库的访问控制系统示意图;

图2是本申请一实施例提供的故障码库的访问控制方法的流程示意图;

图3是本申请另一实施例提供的故障码库的访问控制方法的流程示意图;

图4是本申请另一实施例提供的故障码库的访问控制方法的流程示意图;

图5是本申请实施例提供的故障码库的访问控制装置的结构示意图;

图6是本申请实施例提供的电子设备的结构示意图。

具体实施方式

以下描述中,为了说明而不是为了限定,提出了诸如特定系统结构、技术之类的具体细节,以便透彻理解本申请实施例。然而,本领域的技术人员应当清楚,在没有这些具体细节的其它实施例中也可以实现本申请。在其它情况中,省略对众所周知的系统、装置、电路以及方法的详细说明,以免不必要的细节妨碍本申请的描述。

应当理解,当在本申请说明书和所附权利要求书中使用时,术语“包括”指示所描述特征、整体、步骤、操作、元素和/或组件的存在,但并不排除一个或多个其它特征、整体、步骤、操作、元素、组件和/或其集合的存在或添加。

还应当理解,在本申请说明书和所附权利要求书中使用的术语“和/或”是指相关联列出的项中的一个或多个的任何组合以及所有可能组合,并且包括这些组合。

如在本申请说明书和所附权利要求书中所使用的那样,术语“如果”可以依据上下文被解释为“当...时”或“一旦”或“响应于确定”或“响应于检测到”。类似地,短语“如果确定”或“如果检测到[所描述条件或事件]”可以依据上下文被解释为意指“一旦确定”或“响应于确定”或“一旦检测到[所描述条件或事件]”或“响应于检测到[所描述条件或事件]”。

另外,在本申请说明书和所附权利要求书的描述中,术语“第一”、“第二”、“第三”等仅用于区分描述,而不能理解为指示或暗示相对重要性。

在本申请说明书中描述的参考“一个实施例”或“一些实施例”等意味着在本申请的一个或多个实施例中包括结合该实施例描述的特定特征、结构或特点。由此,在本说明书中的不同之处出现的语句“在一个实施例中”、“在一些实施例中”、“在其他一些实施例中”、“在另外一些实施例中”等不是必然都参考相同的实施例,而是意味着“一个或多个但不是所有的实施例”,除非是以其他方式另外特别强调。术语“包括”、“包含”、“具有”及它们的变形都意味着“包括但不限于”,除非是以其他方式另外特别强调。

图1示出的是本申请实施例提供的一种故障码的访问控制系统10。该系统包括:故障码服务设备110,用户设备120。

其中,故障码服务设备110可以是远程服务器、云端服务器、服务器集群等可以提供故障码信息查询业务的电子设备。

在故障码服务设备通信耦合的存储器中存储故障码库111。故障码(DiagnosticTrouble Code,DTC)为车辆电子控制单元(Electronic Control Unit,ECU)针对每种故障定义的一种编码,故障码还可以被称为事故码、错误码或者其它名称。由于车辆在出现故障时,通常会产生多个故障码,因此故障码可以作为一种辅助维修技术员诊断车辆问题的参数。

故障码信息是故障码对应的文本信息、诊断信息或对故障码的标记数据,通常以文本形式存储。用户设备通过查询故障码库,获取故障码信息来诊断当前故障发生的原因。

故障码库是存储故障码和故障码信息,以及存储故障码和故障码信息对应关系的数据存储形式,一般的以表、数据库、或文本库的方式存储故障码和故障码信息。

其中,用户设备120可以是一种车载设备。车载设备可设置于车辆的车载诊断系统(On-Board Diagnostics,OBD)接口上,通过OBD接口与车辆总线建立连接进而建立与ECU之间的数据连接。车载设备也可通过以其他第三方设备作为中转的方式建立与车辆ECU之间的连接。车载设备通过读取到故障码以及根据故障码从故障码服务设备获取的故障码信息对车辆故障进行诊断。车载设备的形式可为汽车盒子、车载电子设备或可与车机连接的手机等移动终端等其他类型的设备,具体可依据实际情况而定,此处不做限定。

用户设备120与故障码服务设备110可以通过有线和/或无线的通信方式进行通信。具体可依据实际情况而定,此处不做限定。

图2示出了本申请实施例提供的故障码库的访问控制方法,用于处理对故障码库的访问请求,应用于上述图1所示的故障码库的访问控制系统10中的故障码服务设备110,可由所述故障码服务设备110的软件和/或硬件实现。如图2所示,该方法包括步骤S110至S140。各个步骤的具体实现原理如下:

S110,接收用户设备发送的故障码库访问请求,所述故障码库访问请求携带所述用户设备的标识信息。

在一些实施例中,用户设备响应对车辆的诊断指令,对车辆的单个ECU系统,或者整车的多个ECU系统进行故障检测,以获取ECU系统上报的故障码。对车辆的诊断指令可以是用户通过用户设备的操作接口发出的,也可以是用户设备自动触发的。

用户设备在故障检测结束后向故障码服务设备110发送对故障码库的访问请求。该故障码库访问请求中包含用户设备标识。该用户标识信息用于唯一标识用户设备。用户标识信息可以是数字、字母或特殊字符的组合。

在一些实施例中,该访问请求中还可以包含故障码、检测模式、和车型信息至少之一。

故障码服务设备在接收到用户设备发送的访问请求后,响应该访问请求进行故障码访问控制的处理。

S120,根据所述标识信息确定所述用户设备的故障码库访问频次信息。

在一些实施例中,所述故障码库访问频次信息包括:所述用户设备当前发送的所述故障码库访问请求与上一次发送的故障码库访问请求之间的发送时间间隔。故障码服务设备110根据所述标识信息确定所述用户设备的故障码库访问频次信息,可以是记录每次接收用户设备发送的故障码库访问请求的时间,根据当前接收的所述故障码库访问请求与上一次接收的故障码库访问请求之间的发送时间间隔确定该时间间隔。

在一些实施例中,故障码服务设备110根据所述标识信息确定所述用户设备的故障码库访问频次信息,还可以是通过统计预设时间周期内,收到包含所述标识信息的次数,以获得该频次信息。

在一些实施例中,故障码服务设备110根据所述标识信息确定所述用户设备的故障码库访问频次信息,也可以是统计一个时间段内,收到包含所述标识信息的次数,以获得该频次信息。具体的,所述根据所述标识信息确定所述用户设备的故障码库访问频次信息,包括获取所述用户设备发送所述故障码库访问请求的时刻对应的访问时间段;以及,获取所述用户设备在所述访问时间段内发送所述故障码库访问请求的总次数。

S130,基于所述用户设备的故障码库访问频次信息,确定所述用户设备的故障码库访问请求是否存在异常。

在一些实施例中,可以预设频次阈值,预设频次阈值用于限制在预设时间周期内的访问次数上限,当用户设备的故障码库访问频次大于该预设频次阈值,则认为用户设备的故障码库访问请求存在异常。

S140,在所述用户设备的故障码库访问请求存在异常时,对所述用户设备作出异常访问请求响应。

应理解,异常访问请求响应是故障码服务设备针对异常的故障码库访问请求所执行的操作。

在一些实施例中,故障码服务设备对所述用户设备作出异常访问请求响应,包括:故障码服务设备拒绝所述用户设备对所述故障码库的访问。

故障码服务设备拒绝所述用户设备对故障码库的访问同时,或之后,在一些具体的示例中,所述对所述用户设备作出异常访问请求响应,还包括:向所述用户设备发送访问过于频繁的提示信息。在另一些具体的示例中,还可以向所述用户设备发送空白信息,即不包含故障码信息的反馈信息,用于提示用户设备访问过于频繁。在又一些具体的示例中,还可以向用户设备发送异常访问告警信息。

在一些实施例中,所述对所述用户设备作出异常访问请求响应,包括:故障码服务设备要求用户进行身份验证;若验证通过,则放行该用户设备对故障码库的访问;若验证失败,则拒绝所述用户设备对故障码库的访问。要求用户进行身份验证包括但不限于短信或电话验证、验证码验证、生物身份信息验证等验证方式。对用户进行身份验证主要是用于确定当前用户为真实用户,而非针对故障码库的爬虫程序。

在一些实施例中,若所述用户设备的故障码库访问请求不存在异常,故障码服务设备向用户设备作出正常访问请求响应。在一个具体的示例中,正常访问请求响应包括向用户设备反馈故障码对应的故障信息。

应理解,通过根据用户设备发送的故障码库访问请求中的用户设备标识,确定的访问频次信息,并通过该访问频次信息确定故障码库访问请求是否存在异常,可以发现和避免过于频繁的异常访问,从而解决对故障码库的恶意访问的问题。

在一些实施例中,在上述图2所示的故障码库的访问控制方法的实施例的基础上,所述故障码库访问频次信息包括:所述用户设备当前发送的所述故障码库访问请求与上一次发送的所述故障码库访问请求之间的发送时间间隔。如图3所示,步骤S130,所述基于所述用户设备的故障码库访问频次信息,确定所述用户设备的故障码库访问请求是否存在异常,还包括步骤S131至S133:

S131,获取上一次发送的所述故障码库访问请求对应的检测模式。

在一些实施例中,所述检测模式包括单ECU检测模式和全车检测模式。所述检测模式包括单ECU检测模式和全车检测模式。单ECU检测模式是用户设备针对单个ECU系统进行诊断检测的检测模式,全车检测模式是用户设备针对全车的多个ECU系统进行诊断检测的检测模式。

故障码服务设备可以通过获取故障码库访问请求中携带的检测模式信息,来确定用户设备所采用的检测模式。

在一些实施例中,故障码服务设备可以在存储介质中存储每次或存储上一次用户设备发送故障码库访问请求对应的检测模式。存储时间可以是短期暂存,也可以是长期存储,可以根据实际情况确定,这里不做限定。在接收到用户设备发送的当前故障码库访问请求后,通过读取存储介质获取上一次用户设备发送故障码库访问请求对应的检测模式。

S132,根据所述检测模式确定对应的检测时长。

在一些实施中,不同的检测模式具有与该检测模式对应的检测时长。例如,单ECU检测模式的检测时长为10秒,全车检测模式的检测时长为200秒。

S133,若所述用户设备当前发送的所述故障码库访问请求与上一次发送的所述故障码库访问请求之间的发送时间间隔小于所述检测模式对应的检测时长,则确定所述用户设备的故障码库访问请求存在异常。

例如,在单ECU检测模式下,预设检测时长为10秒。若用户设备当前发送的所述故障码库访问请求与上一次发送的所述故障码库访问请求之间的发送时间间隔小于10秒,而该时间间隔不足以用户设备在单ECU检测模式下完成一次检测,因此可以确定用户设备的故障码库访问请求存在异常。

在一些实施例中,所述根据所述检测模式对应的检测时长包括:将所述检测模式下,所述用户设备读取故障码的最短时长,确定为所述检测模式对应的检测时长。

以单ECU检测模式为例,用户设备在单ECU检测模式下获取ECU系统故障码的最小时间间隔为10秒。如果该用户设备在10秒内向故障码服务设别发送了两次或两次以上的故障码库访问请求,并且该故障码库访问请求携带的检测模式为单ECU检测模式,则很可能该用户设备故障码库访问请求是异常的。

以全车检测模式为例,用户设备在单ECU检测模式下需要获取多个ECU系统的故障码,获取多个ECU系统的故障码的最小时间间隔为200秒。如果该用户设备在200秒内向故障码服务设别发送了两次或两次以上的故障码库访问请求,并且该故障码库访问请求携带的检测模式为全车检测模式,则很可能该用户设备故障码库访问请求是异常的。

应理解,通过故障码库访问请求对应的检测模式来确定检测时长,使故障码检测时长的设置更符合实际检测的耗时情况,能够更加准确的判断故障码库访问请求是否为异常的访问请求,从而防止对故障码库的恶意访问。

在上述图2所示的故障码库的访问控制方法的实施例的基础上,如图4所示,步骤S120,所述根据所述标识信息确定所述用户设备的故障码库访问频次信息,可以替换为步骤,S120’,获取所述用户设备发送所述故障码库访问请求的时刻对应的访问时间段;以及,获取所述用户设备在所述访问时间段内发送所述故障码库访问请求的总次数。如图4所示,步骤S130,所述基于所述用户设备的故障码库访问频次信息,确定所述用户设备的故障码库访问请求是否存在异常,可以替换成步骤S130’,若所述总次数大于所述访问时间段对应的预设次数,则确定所述用户设备的故障码库访问请求存在异常。

在一些实施例中,预先将一天的时间划分为若干个访问时间段,每个访问时间段预设最大访问频次。故障码服务设备在获取到用户设备发送的故障码库访问请求后,先根据接收该故障码库访问请求的当前时刻,确定当前时刻对应的访问时间段。在访问时间段内的故障码库访问请求频次超过该时间段的最大访问频次,则将该故障码库访问请求视为异常访问请求。

例如:

禁止访问时段:晚上12点到第二天早上8点,若在该禁止访问时段进行任何频次的访问均为异常访问;

空闲访问时段:早上8点至下午2点,若在该空闲访问时段的访问频次超过第一安全频次,则为异常访问;

繁忙访问时段:下午2点至晚上12点,若在该繁忙访问时段的访问频次超过第二安全频次,则为异常访问。

其中,第一安全频次少于第二安全频次。

在一些实施例中,所述访问控制方法还包括:获取所述用户设备在所述预设访问时间段发送所述故障码库访问请求的概率;基于所述概率确定所述访问时间段对应的预设次数。

通过对正常工作的用户设备发送故障码库访问请求的概率进行统计。根据概率值的变化,将一天的时间划分为几个不同概率值对应的时间段。

例如,将正常工作的用户设备发送故障码库访问请求的概率为0的时间段,设置为禁止访问时段。也就是说,在该时段正常的用户设备是不会发送故障码库访问请求的,若在该禁止访问时段进行任何频次的访问均为异常访问。

又例如,将正常工作的用户设备发送故障码库访问请求的概率较低的时间段,设置为空闲访问时段。也就是说,在该时段正常的用户设备发送故障码库访问请求的频次会比较低,若在该空闲访问时段进行高频次的访问可以认为是异常访问。为该时段设置第一安全频次作为阈值,用来判断用户设备发送故障码库访问请求的频次是否为异常。

再例如,正常工作的用户设备发送故障码库访问请求的概率较高的时间段,市值为繁忙访问时段。也就是说,在该时段正常的用户设备发送故障码库访问请求的频次会比较高,若在该繁忙访问时段进行高频次的访问可以认为是正常访问。可以不对该时段内用户设备发送故障码库访问请求的频次设限,或者对该时段设置较高的故障码库访问请求的频次阈值,以允许用户设备多次发送故障码库访问请求。为该时段设置第二安全频次作为阈值,用来判断用户设备发送故障码库访问请求的频次是否为异常。可以理解的是,第一安全频次少于第二安全频次。

应理解,获取用户设备在所述预设访问时间段发送所述故障码库访问请求的概率,基于所述概率确定所述预设访问时间段对应的预设次数,可以使访问控制的时间段设置更加合理,对异常故障码库访问请求的判断更加准确,进而防止对故障码库的恶意访问。

应理解,上述实施例中各步骤的序号的大小并不意味着执行顺序的先后,各过程的执行顺序应以其功能和内在逻辑确定,而不应对本申请实施例的实施过程构成任何限定。

对应于上述图2所示的故障码库的访问控制方法,图5示出的是本申请实施例提供的一种故障码库的访问控制装置M100,包括:

故障码库访问请求接收模块M110,用于接收用户设备发送的故障码库访问请求,所述故障码库访问请求携带所述用户设备的标识信息.

故障码库访问频次信息确定模块M120,用于根据所述标识信息确定所述用户设备的故障码库访问频次信息。

故障码库访问请求异常确定模块M130,用于基于所述用户设备的故障码库访问频次信息,确定所述用户设备的故障码库访问请求是否存在异常。

异常访问请求响应模块M140,用于在所述用户设备的故障码库访问请求存在异常时,对所述用户设备作出异常访问请求响应。

可选的,所述异常访问请求响应模块,还用于向所述用户设备发送访问过于频繁的提示信息。

可选的,所述故障码库访问频次信息包括:所述用户设备当前发送的所述故障码库访问请求与上一次发送的故障码库访问请求之间的发送时间间隔;

所述故障码库访问请求异常确定模块包括:

检测模式获取模块,用于获取上一次发送的故障码库访问请求对应的检测模式;

检测时长确定模块,用于根据所述检测模式确定对应的检测时长;

时间间隔判断模块,用于若所述用户设备当前发送的所述故障码库访问请求与上一次发送的所述故障码库访问请求之间的发送时间间隔小于所述检测模式对应的检测时长,则确定所述用户设备的故障码库访问请求存在异常。

可选的,所述检测模式包括:单ECU检测模式和全车检测模式。

基于本申请实施例的第二方面,在第四种可能的实现方式中,所述检测时长确定模块包括:

最短时长确定模块,用于将所述检测模式下,所述用户设备读取故障码的最短时长,确定为所述检测模式对应的检测时长。

可选的,故障码库访问频次信息确定模块包括:

访问请求总次数获取模块,用于获取所述用户设备发送所述故障码库访问请求的时刻对应的访问时间段;以及,获取所述用户设备在所述访问时间段内发送所述故障码库访问请求的总次数;

所述故障码库访问请求异常确定模块包括:

总次数判断模块,用于若所述总次数大于所述访问时间段对应的预设次数,则确定所述用户设备的故障码库访问请求存在异常。

可选的,所述访问控制装置还包括:

访问请求概率获取模块,用于获取所述用户设备在所述预设访问时间段发送所述故障码库访问请求的概率;

预设次数确定模块,用于基于所述概率确定所述访问时间段对应的预设次数。

可以理解的是,以上实施例中的各种实施方式和实施方式组合及其有益效果同样适用于本实施例,这里不再赘述。

图6为本申请一实施例提供的电子设备的结构示意图。如图6所示,该实施例的电子设备D10包括:至少一个处理器D100(图6中仅示出一个)处理器、存储器D101以及存储在所述存储器D101中并可在所述至少一个处理器D100上运行的计算机程序D102,所述处理器D100执行所述计算机程序D102时实现上述任意各个方法实施例中的步骤。或者,所述处理器D100执行所述计算机程序D102时实现上述各装置实施例中各模块/单元的功能,例如图5所示模块M110至M140的功能。

在一些实施例中,所述处理器D100执行所述计算机程序D102时实现如下步骤:

接收用户设备发送的故障码库访问请求,所述故障码库访问请求携带所述用户设备的标识信息;

根据所述标识信息确定所述用户设备的故障码库访问频次信息;

基于所述用户设备的故障码库访问频次信息,确定所述用户设备的故障码库访问请求是否存在异常;

在所述用户设备的故障码库访问请求存在异常时,对所述用户设备作出异常访问请求响应。

可选的,所述处理器执行所述计算机程序,实现对所述用户设备作出异常访问请求响应的步骤时,

实现拒绝所述用户设备对所述故障码库的访问的步骤。

可选的,所述故障码库访问频次信息包括:所述用户设备当前发送的所述故障码库访问请求与上一次发送的故障码库访问请求之间的发送时间间隔;

所述处理器执行所述计算机程序,实现所述基于所述用户设备的故障码库访问频次信息,确定所述用户设备的故障码库访问请求是否存在异常的步骤时,实现以下步骤:

获取上一次发送的故障码库访问请求对应的检测模式;

根据所述检测模式确定对应的检测时长;

若所述用户设备当前发送的所述故障码库访问请求与上一次发送的所述故障码库访问请求之间的发送时间间隔小于所述检测模式对应的检测时长,则确定所述用户设备的故障码库访问请求存在异常。

可选的,所述检测模式包括:单ECU检测模式和全车检测模式。

可选的,所述处理器执行所述计算机程序,实现所述根据所述检测模式确定对应的检测时长的步骤时,

实现将所述检测模式下,所述用户设备读取故障码的最短时长,确定为所述检测模式对应的检测时长的步骤。

可选的,所述处理器执行所述计算机程序,实现所述根据所述标识信息确定所述用户设备的故障码库访问频次信息的步骤时,

实现获取所述用户设备发送所述故障码库访问请求的时刻对应的访问时间段;以及,

获取所述用户设备在所述访问时间段内发送所述故障码库访问请求的总次数的步骤;

所述处理器执行所述计算机程序,实现所述基于所述用户设备的故障码库访问频次信息,确定所述用户设备的故障码库访问请求是否存在异常的步骤时,

实现若所述总次数大于所述访问时间段对应的预设次数,则确定所述用户设备的故障码库访问请求存在异常的步骤。

所述处理器执行所述计算机程序时,还实现如下步骤:

获取所述用户设备在所述预设访问时间段发送所述故障码库访问请求的概率;

基于所述概率确定所述访问时间段对应的预设次数。

所述电子设备D10可以是桌上型计算机、笔记本、掌上电脑及云端服务器等计算设备。该电子设备可包括,但不仅限于,处理器D100、存储器D101。本领域技术人员可以理解,图6仅仅是电子设备D10的举例,并不构成对电子设备D10的限定,可以包括比图示更多或更少的部件,或者组合某些部件,或者不同的部件,例如还可以包括输入输出设备、网络接入设备等。

所称处理器D100可以是中央处理单元(Central Processing Unit,CPU),该处理器D100还可以是其他通用处理器、数字信号处理器(Digital Signal Processor,DSP)、专用集成电路(Application Specific Integrated Circuit,ASIC)、现成可编程门阵列(Field-Programmable Gate Array,FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。

所述存储器D101在一些实施例中可以是所述电子设备D10的内部存储单元,例如电子设备D10的硬盘或内存。所述存储器D101在另一些实施例中也可以是所述电子设备D10的外部存储设备,例如所述电子设备D10上配备的插接式硬盘,智能存储卡(Smart MediaCard,SMC),安全数字(Secure Digital,SD)卡,闪存卡(Flash Card)等。进一步地,所述存储器D101还可以既包括所述电子设备D10的内部存储单元也包括外部存储设备。所述存储器D101用于存储操作系统、应用程序、引导装载程序(BootLoader)、数据以及其他程序等,例如所述计算机程序的程序代码等。所述存储器D101还可以用于暂时地存储已经输出或者将要输出的数据。

需要说明的是,上述装置/单元之间的信息交互、执行过程等内容,由于与本申请方法实施例基于同一构思,其具体功能及带来的技术效果,具体可参见方法实施例部分,此处不再赘述。

所属领域的技术人员可以清楚地了解到,为了描述的方便和简洁,仅以上述各功能单元、模块的划分进行举例说明,实际应用中,可以根据需要而将上述功能分配由不同的功能单元、模块完成,即将所述装置的内部结构划分成不同的功能单元或模块,以完成以上描述的全部或者部分功能。实施例中的各功能单元、模块可以集成在一个处理单元中,也可以是各个单元单独物理存在,也可以两个或两个以上单元集成在一个单元中,上述集成的单元既可以采用硬件的形式实现,也可以采用软件功能单元的形式实现。另外,各功能单元、模块的具体名称也只是为了便于相互区分,并不用于限制本申请的保护范围。上述系统中单元、模块的具体工作过程,可以参考前述方法实施例中的对应过程,在此不再赘述。

本申请实施例还提供了一种计算机可读存储介质,所述计算机可读存储介质存储有计算机程序,所述计算机程序被处理器执行时可实现上述各个方法实施例中的步骤。

本申请实施例提供了一种计算机程序产品,当计算机程序产品在电子设备上运行时,使得电子设备执行时可实现上述各个方法实施例中的步骤。

所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时,可以存储在一个计算机可读取存储介质中。基于这样的理解,本申请实现上述实施例方法中的全部或部分流程,可以通过计算机程序来指令相关的硬件来完成,所述的计算机程序可存储于一计算机可读存储介质中,该计算机程序在被处理器执行时,可实现上述各个方法实施例的步骤。其中,所述计算机程序包括计算机程序代码,所述计算机程序代码可以为源代码形式、对象代码形式、可执行文件或某些中间形式等。所述计算机可读介质至少可以包括:能够将计算机程序代码携带到拍照装置/终端设备的任何实体或装置、记录介质、计算机存储器、只读存储器(Read-Only Memory,ROM)、随机存取存储器(Random AccessMemory,RAM)、电载波信号、电信信号以及软件分发介质。例如U盘、移动硬盘、磁碟或者光盘等。在某些司法管辖区,根据立法和专利实践,计算机可读介质不可以是电载波信号和电信信号。

在上述实施例中,对各个实施例的描述都各有侧重,某个实施例中没有详述或记载的部分,可以参见其它实施例的相关描述。

本领域普通技术人员可以意识到,结合本文中所公开的实施例描述的各示例的单元及算法步骤,能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行,取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能,但是这种实现不应认为超出本申请的范围。

在本申请所提供的实施例中,应该理解到,所揭露的装置/网络设备和方法,可以通过其它的方式实现。例如,以上所描述的装置/网络设备实施例仅仅是示意性的,例如,所述模块或单元的划分,仅仅为一种逻辑功能划分,实际实现时可以有另外的划分方式,例如多个单元或组件可以结合或者可以集成到另一个系统,或一些特征可以忽略,或不执行。另一点,所显示或讨论的相互之间的耦合或直接耦合或通讯连接可以是通过一些接口,装置或单元的间接耦合或通讯连接,可以是电性,机械或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的,作为单元显示的部件可以是或者也可以不是物理单元,即可以位于一个地方,或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

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

技术分类

06120113793024