用于识别车辆服务任务的异常的方法及电子设备与流程

摘要: 本技术涉及车辆领域,尤其涉及一种用于识别车辆服务任务的异常的方法、一种计算机程序产品以及一种电子设备。背景技术:1、随着智能网联车辆的快速发展,车辆与后台服务器...
用于识别车辆服务任务的异常的方法及电子设备与流程

本技术涉及车辆领域,尤其涉及一种用于识别车辆服务任务的异常的方法、一种计算机程序产品以及一种电子设备。

背景技术:

1、随着智能网联车辆的快速发展,车辆与后台服务器(例如云端服务平台)之间的交互日益频繁。用户可通过移动终端或车机终端触发远程控制空调、充电管理等各类车辆服务的激活和/或去激活。后台服务器可响应于触发指令,相应地执行被触发的车辆服务任务,即车辆服务的激活和/或去激活。

2、现有技术在车辆服务的激活和/或去激活过程的异常识别方面仍然存在不足。当车辆服务的激活或去激活任务被触发后,如果最终执行失败,运维人员可收到指示激活或去激活任务执行失败的反馈。基于该“失败”的执行结果,运维人员可进行故障排查。然而,当车辆服务的激活或去激活任务被触发并且最终执行成功时,运维人员往往仅能获取“成功”的执行结果,而无法及时、有效地发现执行过程中出现的中间异常。即使某些车辆服务的激活/去激活任务在执行过程中出现过异常状况,但只要车辆服务的激活和/或去激活最终成功完成,这些中间过程的异常状况便难以被及时发现和处理。这进而导致潜在的故障风险持续累积。

3、因此,现有的技术方案仍有待进一步改进。

技术实现思路

1、本技术的目的在于提供一种改进的用于识别车辆服务任务的异常的方法以及相应的计算机程序产品和电子设备,以克服现有技术的不足中的至少一者。

2、根据本技术的第一方面,提供了一种用于识别车辆服务任务的异常的方法,其应用于后台服务器,所述方法包括以下步骤:

3、-根据车辆服务任务在被成功完成的情况下的历史执行时长,建立和/或更新车辆服务任务的时长分布模型,所述车辆服务任务包括车辆服务的激活任务和/或车辆服务的去激活任务;

4、-响应于对车辆服务任务的触发请求,执行车辆服务任务;

5、-在成功完成车辆服务任务之后,确定所述车辆服务任务所用的实际执行时长;以及

6、-根据所述车辆服务任务所用的实际执行时长基于时长分布模型识别所述车辆服务任务是否存在异常。

7、由此,能够利用车辆服务任务所用的实际执行时长来识别所述车辆服务任务是否存在异常。这特别有助于识别原本难以识别的隐性异常。与仅通过车辆服务任务的执行结果(成功或失败)来判断是否存在异常相比,根据本技术的用于识别车辆服务任务的异常的方法能够更全面地监测车辆服务任务的执行情况。特别是,能够有效地识别车辆服务任务的中间过程异常(如重试、功能失效)。由此,能够准确地监测后台服务器的运行情况,及时地识别到可能存在的异常。根据历史执行时长来建立和/或更新时长分布模型能够提供用于准确地识别异常的判断标准,并且无需依赖技术人员的经验。本技术的构思聚焦于车辆服务任务的难以识别的中间过程异常。仅采用成功完成的车辆服务任务的历史执行时长,有助于防止异常数据污染时长分布模型。

8、根据本技术的一个可选实施例,确定所述车辆服务任务所用的实际执行时长包括:根据后台服务器在执行车辆服务任务的过程中所经历的所有子任务功能的停留时长,确定所述车辆服务任务所用的实际执行时长。

9、由此得到的实际执行时长能够更准确地反映后台服务器在执行车辆服务任务的各个环节的实际耗时,并且能够为后续进行异常定位提供更精确的数据。此外,在车辆服务任务包括并行处理的子功能任务的情况下,通过这种方式得到的实际执行时长能够更全面地反映出车辆服务任务的执行过程,有助于准确地识别可能存在的异常。

10、特别是,可利用下述关系式确定车辆服务任务所用的实际执行时长:

11、

12、其中,t表示车辆服务任务所用的实际执行时长,n表示车辆服务任务所经历的所有子任务功能的数量,tk表示第k个子任务功能的停留时长。

13、根据本技术的一个可选实施例,确定所述车辆服务任务所用的实际执行时长包括:

14、-根据所述车辆服务任务的触发请求的时间戳确定起始时刻;

15、-根据接收到的车辆服务任务完成的完成反馈的时间戳确定终止时刻;以及

16、-计算起始时刻与终止时刻之间的时间差作为所述车辆服务任务的实际执行时长。

17、由此,能够通过便于实现的方式确定车辆服务任务的实际执行时长。实际执行时长的计算过程仅需非常少的计算资源,不影响各子任务功能。此外,该设计特别有助于实现轻量化且低成本的部署,无需深入改造各子任务功能的内部流程,对现有的业务代码的侵入性极低,便于快速集成到已有的后台服务器。

18、根据本技术的一个可选实施例,建立和/或更新车辆服务任务的时长分布模型包括:以车辆服务任务的历史实际执行时长的均值μ和标准差σ作为模型参数建立和/或更新正态分布模型。

19、根据本技术的一个可选实施例,根据所述车辆服务任务所用的实际执行时长基于时长分布模型识别所述车辆服务任务是否存在异常包括:

20、-根据所述正态分布模型,确定正常时长区间;

21、-判断所述车辆服务任务所用的实际执行时长是否落入所述正常时长区间以确定车辆服务任务是否存在异常。

22、所述正常时长区间特别是被确定为[μ,μ+2σ]。如此设置的正常时长区间能够减少误报和漏报。

23、根据本技术的一个可选实施例,如果所述实际执行时长不在所述正常时长区间内,则调用车辆服务任务所经历的子任务功能的错误日志,生成告警通知。所述告警通知特别是包括下述信息中的至少一者:实际执行时长、正常时长区间、触发异常的子任务功能的标识、异常类型、相关错误日志。

24、告警通知能够提醒运维人员进行排查。此外,告警通知还能够提供用于进行故障排查所需的关键信息,并且能够引导排查的方向。

25、根据本技术的一个可选实施例,如果所述实际执行时长超过所述正常时长区间的上限,则执行以下步骤:

26、-调用车辆服务任务所经历的子任务功能的错误日志;

27、-检查各子任务功能的错误日志中是否包括重试机制被触发的记录;以及

28、-若检测到至少一个子任务功能触发了重试机制,则生成包含所述至少一个子任务功能的标识的第一告警通知。

29、尽管重试机制的触发并未影响车辆服务任务的执行结果,但这表现出了该子任务功能存在稳定性隐患。通过及时地识别到这种稳定性隐患的存在并且进而找到和解决这种稳定性隐患,能够防止问题持续累积导致更严重的服务中断。通过精确定位到触发了重试机制的具体子任务功能,有助于使运维人员快速地找到导致异常的原因,缩短故障定位时间。

30、根据本技术的一个可选实施例,如果所述实际执行时长低于所述正常时长区间的下限,则生成指示存在子任务功能停止运行的风险的第二告警通知。

31、通过识别第二类异常,能够防止这种不完整的车辆服务任务影响车辆安全性和功能完整性。第二告警通知能够引导异常的排查方向,运维人员无需猜测异常类型即可快速采取相应的措施。

32、根据本技术的第二方面,提供了一种计算机程序产品,其包括计算机程序指令,其中,所述计算机程序指令当被一个或多个处理器执行时使得所述一个或多个处理器能够执行根据本技术的示例性实施例的用于识别车辆服务任务的异常的方法。

33、根据本技术的第三方面,提供了一种电子设备,其中,所述电子设备包括存储器和处理器,其中,所述存储器存储有计算机程序,当所述计算机程序被所述处理器执行时,所述处理器能够执行根据本技术的示例性实施例的用于识别车辆服务任务的异常的方法。