车辆服务监控方法、装置、系统及存储介质与流程

1.本技术涉及车辆检测技术领域，具体涉及一种车辆服务监控方法、装置、系统及存储介质。


背景技术：

2.随着汽车智能化技术的不断发展，为了实现车辆软件与硬件的解耦，车厂逐渐开始采用soa架构来实现车辆的控制功能，但是，由于soa架构的服务数量比较多，层级又比较复杂，当功能出现异常时一般不容易发现异常原因。


技术实现要素：

3.为了解决如何快速定位功能异常的原因的技术问题，本技术提供了一种车辆服务监控方法、装置、系统及存储介质。
4.第一方面，本技术提供了一种车辆服务监控方法，所述方法包括：
5.获取车辆服务的调用请求；其中，所述车辆服务包括至少两个服务层级；
6.根据所述调用请求，生成每个所述服务层级的调用关系；
7.根据所述调用关系获取对应的所述服务层级的实际调用次数和实际被调用次数；
8.根据所述实际调用次数和所述实际被调用次数以及预设的服务调用规则对各个所述服务层级进行监控，以判断所述服务层级是否存在异常；
9.可选地，根据所述实际调用次数和所述实际被调用次数以及预设的服务调用规则对各个所述服务层级进行监控，以判断所述服务层级是否存在异常，包括：
10.获取所述服务调用规则，其中，所述服务调用规则至少包括异常判断规则，以及每个调用请求中每个所述服务层级的理论调用次数和理论被调用次数；
11.根据所述实际调用次数、所述实际被调用次数、所述理论调用次数、所述理论被调用次数和所述异常判断规则判断各个所述服务层级是否存在异常；
12.可选地，所述服务层级存在异常包括调用方异常、被调用方异常和设计异常，根据所述实际调用次数、所述实际被调用次数、所述理论调用次数、所述理论被调用次数和所述异常判断规则判断各个所述服务层级是否存在异常，包括：
13.在一组调用关系中，一个调度周期内所述服务层级作为调用方发起的理论调用次数为一次，若所述服务层级发起的所述实际调用次数大于所述理论调用次数，则判断所述服务层级存在调用方异常；
14.在一组调用关系中，一个调度周期内所述服务层级作为被调用方的所述实际被调用次数小于所述理论被调用次数，则判断所述服务层级存在被调用方异常；
15.在一组调用关系中，一个调度周期内所述服务层级作为被调用方的所述实际被调用次数大于所述理论被调用次数，则判断所述服务层级存在设计异常；
16.可选地，获取车辆服务的调用请求之前，所述方法还包括：
17.为每一个所述服务层级配置标识信息，所述标识信息用于指示所述服务层级；
18.相应地，所述调用关系携带调用方的所述标识信息和被调用方的所述标识信息；
19.可选地，根据所述调用次数和所述被调用次数以及预设的服务调用规则对各个所述服务层级进行监控，以判断所述服务层级是否存在异常之后，所述方法还包括：
20.获取出现异常的服务层级的参数信息；其中，所述参数信息至少包括服务层级标识、异常类型和异常发生时间；
21.将所述参数信息发送到日志存储模块进行本地存储，和/或，发送到日志上传模块进行云端存储，以使本地和/或云端根据所述参数信息定位异常服务；
22.可选地，所述服务层级包括场景服务层、系统服务层、增强服务层、原子服务层、输入输出抽象层和基础服务层；
23.其中，所述场景服务层允许被外部调用；
24.所述系统服务层允许被所述场景服务层调用；
25.所述增强服务层允许被所述系统服务层调用；
26.所述原子服务层允许被所述增强服务层调用；
27.所述输入输出抽象层允许被所述原子服务层调用；
28.所述基础服务层允许被所述场景服务层、所述系统服务层、所述增强服务层、所述原子服务层调用。
29.第二方面，本技术提供了一种车辆服务监控系统，所述系统包括：服务监控模块、处理模块和日志模块；
30.所述服务监控模块，用于获取车辆服务的调用请求；其中，所述车辆服务包括至少两个服务层级；根据所述调用请求，生成每个所述服务层级的调用关系；
31.所述处理模块，用于根据所述调用关系获取对应的所述服务层级的实际调用次数和实际被调用次数；根据所述实际调用次数和所述实际被调用次数以及预设的服务调用规则对各个所述服务层级进行监控，以判断所述服务层级是否存在异常，并将异常的所述服务层级的参数信息发送至所述日志模块存储。
32.第三方面，本技术提供了一种车辆服务监控装置，所述装置包括：
33.第一获取模块，用于获取车辆服务的调用请求；其中，所述车辆服务包括至少两个服务层级；
34.生成模块，用于根据所述调用请求，生成每个所述服务层级的调用关系；
35.第二获取模块，用于根据所述调用关系获取对应的所述服务层级的实际调用次数和实际被调用次数；
36.监控判断模块，用于根据所述实际调用次数和所述实际被调用次数以及预设的服务调用规则对各个所述服务层级进行监控，以判断所述服务层级是否存在异常。
37.第四方面，本技术提供了一种电子装置，包括处理器、通信接口、存储器和通信总线，其中，处理器，通信接口，存储器通过通信总线完成相互间的通信；
38.存储器，用于存放计算机程序；
39.处理器，用于执行存储器上所存放的程序时，实现第一方面任一项实施例所述的车辆服务监控方法的步骤。
40.第五方面，本技术提供了一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现如第一方面任一项实施例所述的车辆服务监控方法的步
骤。
41.本技术的有益效果：
42.本技术实施例提供的该方法，获取车辆服务的调用请求；其中，所述车辆服务包括至少两个服务层级；根据所述调用请求，生成每个所述服务层级的调用关系；根据所述调用关系获取对应的所述服务层级的实际调用次数和实际被调用次数；根据所述实际调用次数和所述实际被调用次数以及预设的服务调用规则对各个所述服务层级进行监控，以判断所述服务层级是否存在异常。该方法，可以根据调用请求，生成每个服务层级的调用关系，并进一步获取每个服务层级的实际调用次数和实际被调用次数，从而可以根据调用次数是否符合预设的服务调用规则对各个服务层级进行监控，并对调用次数异常的服务层级进行精准定位，可快捷高效的解决功能异常时的定位问题，提高了故障处理的效率。
附图说明
43.此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本技术的实施例，并与说明书一起用于解释本技术的原理。
44.为了更清楚地说明本技术实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，对于本领域普通技术人员而言，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
45.图1为本技术一个实施例提供的一种车辆服务监控方法的系统架构图；
46.图2为本技术一个实施例提供的一种车辆服务监控方法的流程示意图；
47.图3为本技术一个实施例提供的一种服务层级调用的示意图；
48.图4为本技术另一个实施例提供的一种车辆服务监控方法的系统架构图；
49.图5为本技术另一个实施例提供的一种车辆服务监控方法的流程示意图；
50.图6为本技术一个实施例提供的一种调用关系示意图；
51.图7为本技术一个实施例提供的一种车辆服务监控装置的结构示意图；
52.图8为本技术一个实施例提供的一种电子装置的结构示意图。
具体实施方式
53.以下将参照附图和优选实施例来说明本技术的实施方式，本领域技术人员可由本说明书中所揭露的内容轻易地了解本技术的其他优点与功效。本技术还可以通过另外不同的具体实施方式加以实施或应用，本说明书中的各项细节也可以基于不同观点与应用，在没有背离本技术的精神下进行各种修饰或改变。应当理解，优选实施例仅为了说明本技术，而不是为了限制本技术的保护范围。
54.本技术第一实施例提供了一种车辆服务监控方法，该方法可以应用于如图1所示的系统架构，该系统架构中至少包括服务监控模块101、处理模块102和日志模块103，该服务监控模块101和日志模块103分别与处理模块102建立通信连接。
55.服务监控模块101，用于获取车辆服务的调用请求，其中，车辆服务包括至少两个服务层级；根据调用请求，生成每个服务层级的调用关系。
56.处理模块102，用于根据调用关系获取对应的服务层级的实际调用次数和实际被调用次数，根据实际调用次数和实际被调用次数以及预设的服务调用规则对各个服务层级
进行监控，以判断服务层级是否存在异常，并将异常的服务层级的参数信息发送至日志模块103存储。
57.其中，服务监控模块101可包括多个子模块，子模块与服务层级的数量相同且一一对应，对服务层级进行监控。
58.接下来，基于该系统架构，对该车辆服务监控方法进行详细说明，如图2，车辆服务监控方法包括：
59.步骤201，获取车辆服务的调用请求，其中，车辆服务包括至少两个服务层级。
60.本实施例中，车辆的服务层级可以包括多种，比如，如图3所示，服务层级包括场景服务层、系统服务层、增强服务层、原子服务层、输入输出抽象层(也称为i/o抽象服务层)和基础服务层。
61.其中，场景服务层允许被外部调用，系统服务层允许被场景服务层调用，增强服务层允许被系统服务层调用，原子服务层允许被增强服务层调用，输入输出抽象层允许被原子服务层调用，基础服务层允许被场景服务层、系统服务层、增强服务层、原子服务层调用。
62.需要说明的是，服务层级的种类及个数可以根据需要进行配置，不作限制。
63.步骤202，根据调用请求，生成每个服务层级的调用关系。
64.每个服务层级可以包括多种不同的具体的服务，不同的服务可以对应不同的调用关系，可以根据不同的调用请求，生成该调用请求下每个服务层级的调用关系，具体地，可以由每个服务层级对应的服务监控模块对该服务层级进行监控，并根据调用请求生成该服务层级的调用关系。
65.步骤203，根据调用关系获取对应的服务层级的实际调用次数和实际被调用次数。
66.在调用关系确定后，可以确定涉及到的各个服务层级的具体服务，可以方便的由处理模块获取各个服务层级的实际调用次数和实际被调用次数。
67.步骤204，根据实际调用次数和实际被调用次数以及预设的服务调用规则对各个服务层级进行监控，以判断服务层级是否存在异常。
68.该方法，可以根据调用请求，生成每个服务层级的调用关系，并进一步获取每个服务层级的实际调用次数和实际被调用次数，从而可以根据调用次数是否符合预设的服务调用规则对各个服务层级进行监控，并对调用次数异常的服务层级进行精准定位，可快捷高效的解决功能异常时的定位问题，提高了故障处理的效率。
69.一个实施例中，根据实际调用次数和实际被调用次数以及预设的服务调用规则对各个服务层级进行监控，以判断服务层级是否存在异常，包括：获取服务调用规则，根据实际调用次数、实际被调用次数、理论调用次数、理论被调用次数和异常判断规则判断各个服务层级是否存在异常。
70.本实施例中，服务调用规则可以包括异常判断规则，以及每个调用请求中每个服务层级的理论调用次数和理论被调用次数，从而可以根据各个服务层级的实际调用次数和理论调用次数是否一致来判断服务层级是否存在异常，实际调用次数和理论调用次数不一致的服务层级即可判断为出现异常的服务层级，进而可以根据该调用请求涉及到的该服务层级的具体服务来精准定位功能异常的问题根源，提高处理问题的效率。
71.具体地，服务层级存在异常包括调用方异常、被调用方异常和设计异常，服务层级既可以是调用方也可以是被调用方，比如，场景服务层可以调用系统服务层，系统服务层可
以调用增强服务层，此时，系统服务层是场景服务层的被调用方，也是增强服务层的调用方，系统服务层出现异常时，可能是在调用增强服务层时出现调用方异常，也可能是在被场景服务层调用时出现被调用方异常。通过对服务层级在调用或者被调用时的异常进行细分，可以进一步的提高问题定位的速度和效率。
72.本实施例中，一个服务层级作为调用方只对下一服务层级发起一次调用，一次调用可以针对下一服务层级的多个服务，即调用关系可以是一对一的调用，也可以是一对多的调用。
73.具体地，根据实际调用次数、理论调用次数和异常判断规则判断各个服务层级是否存在异常，可以至少包括以下几种情况：
74.第一种情况，在一组调用关系中，一个调度周期内服务层级作为调用方发起的理论调用次数为一次，若服务层级发起的实际调用次数大于理论调用次数，则判断服务层级存在调用方异常。
75.第二种情况，在一组调用关系中，一个调度周期内服务层级作为被调用方的实际被调用次数小于理论被调用次数，则判断服务层级存在被调用方异常。
76.第三种情况，在一组调用关系中，一个调度周期内服务层级作为被调用方的实际被调用次数大于理论被调用次数，则判断服务层级存在设计异常，可能有服务不满足设计规则，出现跨层级调用或者被外部异常调用，需要对服务进行重新设计修改。
77.需要说明的是，调度周期可以根据需要设置，比如设置10ms，在10ms内，只按照调用关系进行一次各个服务层级的逐级调用，不作限制。
78.一个实施例中，获取车辆服务的调用请求之前，方法还包括：为每一个服务层级配置标识信息，标识信息用于指示服务层级，相应地，调用关系可以携带调用方的标识信息和被调用方的标识信息。
79.其中，标识信息可以是设定的区分服务层级的编号，通过该编号可以直观的了解该编号对应哪个服务层级，提高问题定位时的效率。
80.对于一些偶发性问题，很难再现问题，可以对异常的参数信息进行分析从而准确定位问题。
81.一个实施例中，根据调用次数和被调用次数以及预设的服务调用规则对各个服务层级进行监控，以判断服务层级是否存在异常之后，方法还包括：获取出现异常的服务层级的参数信息；其中，参数信息可以包括服务层级标识、异常类型和异常发生时间，当然，也可以包括其他可以辅助对问题进行定位的参数，不作限制，接下来，可以将参数信息发送到日志存储模块进行本地存储，也可以将参数信息发送到日志上传模块进行云端存储，以使本地和云端根据参数信息定位异常服务。
82.本实施例中，对于偶发性问题，可通过回放本地日志或拉取云端日志来定位异常服务，亦或是排除服务调用异常，缩小进一步排查范围，提高工作效率。
83.在一个具体地实施例中，以车辆服务包括图3中的服务层级举例说明，该方法可应用于如图4所示的系统架构。
84.在该具体地系统架构中，包括场景服务监控模块、系统服务监控模块、增强服务监控模块、原子服务监控模块、i/o抽象服务监控模块、基础服务监控模块、处理模块、日志存储模块和日志上传模块。
85.场景服务监控模块，用于监控场景服务层每一个服务调用和被调用的次数，同时生成调用关系，场景服务层为外部提供调用接口，也可调用系统服务层和基础服务层的服务。
86.系统服务监控模块，用于监控系统服务层每一个服务调用和被调用的次数，同时生成调用关系，系统服务层为场景服务层提供调用接口，也可调用增强服务层和基础服务层的服务，还用于内部控制逻辑的触发。
87.增强服务监控模块，用于监控增强服务层每一个服务调用和被调用的次数，同时生成调用关系，增强服务层为系统服务层提供调用接口，也可调用原子服务层和基础服务层的服务。
88.原子服务监控模块，用于监控原子服务层每一个服务调用和被调用的次数，同时生成调用关系，原子服务层为增强服务层提供调用接口，也可调用i/o抽象层和基础服务层的服务。
89.i/o抽象服务监控模块，用于监控i/o抽象层每一个服务被调用的次数，i/o抽象层为原子服务层提供调用接口，与硬件关联绑定，用于获取硬件的状态变化信号。
90.基础服务监控模块，用于监控基础服务层每一个服务被调用的次数，基础服务层为场景服务层、系统服务层、增强服务层和原子服务层提供调用接口，主要用于eeprom数据存储。
91.处理模块，用于获取每个层级服务监控的数据和日志，以及对服务调用异常进行识别和判断，同时记录异常服务编号、异常类型、执行参数等，发出日志存储和上传指令。
92.日志存储模块，用于接收处理模块的存储指令，将日志存储在本地，便于后续读取。
93.日志上传模块，用于接收处理模块的上传指令，将日志上传至云端。
94.一种车辆服务监控方法，如图5，方法包括：
95.步骤501，为每一个服务编号。编号可直观识别服务层级，例如场景服务a编号为1001，场景服务b编号为1002，系统服务a编号为2001，增强服务a编号为3001。
96.步骤502，各个服务层监控模块实时监控调用请求。
97.步骤503，当有调用请求发生时，监控模块生成一组或多组调用关系，并将调用关系发送至处理模块，调用关系包括调用方编号和被调用方编号，一组调用关系里面通常为一对一或一对多的形式。
98.以遥控解锁举例说明，生成的调用关系如图6所示，其中2001为钥匙检测系统服务，当按下一次解锁按键时，2001开始执行调用，同时调用四个门锁的增强服务，即左前门锁增强服务3001、右前门锁增强服务3002、左后门锁增强服务3003、右后门锁增强服务3004，当门锁增强服务被调用时，门锁增强服务又会继续调用对应门锁的原子服务，即4001、4002、4003、4004，接着原子服务继续调用i/o抽象服务，即5001、5002、5003、5004。
99.步骤504，处理模块根据调用关系获取对应服务的调用和被调用次数，进而判断一个调度周期内是否有异常。
100.步骤505，处理模块将异常进行分类，同时获取异常服务的相关参数。异常可分为调用方异常、被调用方异常、设计异常。
101.当出现异常时，获取异常服务的编号、异常类型、执行参数、时间等信息，并发送至
日志存储模块和日志上传模块。
102.以遥控解锁调用关系为例，正常情况下，系统服务2001只会发起一次调用，若一个调度周期10ms内，2001发起多次调用，则识别为调用方异常，同理，增强服务3001也只会发起一次调用，若一个调度周期10ms内，3001发起多次调用，也识别为调用方异常。
103.在增强服务3001调用原子服务4001时，若3001成功发起1次调用，而4001被调用的次数为0，则识别为被调用方异常。
104.在原子服务4001调用io抽象5001时，若4001成功发起1次调用，而5001被调用的次数为2，则识别为设计异常。
105.步骤506，日志存储模块和日志上传模块分别将异常数据存储和上传。
106.本实施例中，当出现遥控解锁不成功时，如果是因为服务调用异常导致的问题，则可以根据日志快速定位异常的服务，便于快速解决问题。
107.本实施例的车辆服务监控方法，至少具有以下技术效果：
108.当功能出现异常时，如果发生了服务调用异常，可快速锁定问题原因，定位异常服务，更快捷高效；对于一些偶发性问题，很难再现问题，可通过回放本地日志或拉取云端日志来定位异常服务，亦或是排除服务调用异常，缩小进一步排查范围，提高工作效率。
109.需要说明的是，本实施例的具体服务层级和对应的服务监控模块均为举例说明，不代表对其种类和数量进行的限制。
110.基于同一技术构思，本技术第二实施例提供了一种车辆服务监控装置，如图7，所述装置包括：
111.第一获取模块701，用于获取车辆服务的调用请求；其中，所述车辆服务包括至少两个服务层级；
112.生成模块702，用于根据所述调用请求，生成每个所述服务层级的调用关系；
113.第二获取模块703，用于根据所述调用关系获取对应的所述服务层级的实际调用次数和实际被调用次数；
114.监控判断模块704，用于根据所述实际调用次数和所述实际被调用次数以及预设的服务调用规则对各个所述服务层级进行监控，以判断所述服务层级是否存在异常。
115.该装置，可以根据调用请求，生成每个服务层级的调用关系，并进一步获取每个服务层级的实际调用次数和实际被调用次数，从而可以根据调用次数是否符合预设的服务调用规则对各个服务层级进行监控，并对调用次数异常的服务层级进行精准定位，可快捷高效的解决功能异常时的定位问题，提高了故障处理的效率。
116.如图8所示，本技术第三实施例提供了一种电子装置，包括处理器111、通信接口112、存储器113和通信总线114，其中，处理器111，通信接口112，存储器113通过通信总线114完成相互间的通信，
117.存储器113，用于存放计算机程序；
118.在一个实施例中，处理器111，用于执行存储器113上所存放的程序时，实现前述任意一个方法实施例提供的车辆服务监控方法。
119.上述电子装置中的存储器、处理器通过通信总线和通信接口进行通信。通信总线可以是外设部件互连标准(peripheral component interconnect，简称pci)总线或扩展工业标准结构(extended industry standard architecture，简称eisa)总线等。该通信总线
可以分为地址总线、数据总线、控制总线等。
120.存储器可以包括随机存取存储器(random access memory，简称ram)，也可以包括非易失性存储器(non-volatile memory)，例如至少一个磁盘存储器。可选的，存储器还可以是至少一个位于远离前述处理器的存储装置。
121.上述的处理器可以是通用处理器，包括中央处理器(central processing unit，简称cpu)、网络处理器(network processor，简称np)等；还可以是数字信号处理器(digital signal processing，简称dsp)、专用集成电路(application specific integrated circuit，简称asic)、现场可编程门阵列(field-programmable gate array，简称fpga)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。
122.本技术第四实施例提供了一种具有处理器可执行的非易失的程序代码的计算机可读介质。
123.可选地，在本技术实施例中，计算机可读介质被设置为存储用于处理器执行上述方法的程序代码。
124.可选地，本实施例中的具体示例可以参考上述实施例中所描述的示例，本实施例在此不再赘述。
125.本技术实施例在具体实现时，可以参阅上述各个实施例，具有相应的技术效果。
126.可以理解的是，本文描述的这些实施例可以用硬件、软件、固件、中间件、微码或其组合来实现。对于硬件实现，处理单元可以实现在一个或多个专用集成电路(application specific integrated circuits，asic)、数字信号处理器(digital signal processing，dsp)、数字信号处理设备(dsp device，dspd)、可编程逻辑设备(programmable logic device，pld)、现场可编程门阵列(field-programmable gate array，fpga)、通用处理器、控制器、微控制器、微处理器、用于执行本技术功能的其它电子单元或其组合中。
127.对于软件实现，可通过执行本文功能的单元来实现本文的技术。软件代码可存储在存储器中并通过处理器执行。存储器可以在处理器中或在处理器外部实现。
128.本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本技术的范围。
129.所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统、装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。
130.在本技术所提供的实施例中，应该理解到，所揭露的装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，模块的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个模块或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。
131.作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络
单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
132.另外，在本技术各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。
133.功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本技术实施例的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本技术各个实施例方法的全部或部分步骤。而前述的存储介质包括：u盘、移动硬盘、rom、ram、磁碟或者光盘等各种可以存储程序代码的介质。
134.需要说明的是，在本文中，诸如“第一”和“第二”等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个
……”
限定的要素，并不排除在包括要素的过程、方法、物品或者设备中还存在另外的相同要素。
135.以上实施例仅是为充分说明本技术而所举的较佳的实施例，本技术的保护范围不限于此。本技术领域的技术人员在本技术基础上所作的等同替代或变换，均在本技术的保护范围之内。

技术特征：
1.一种车辆服务监控方法，其特征在于，所述方法包括：获取车辆服务的调用请求；其中，所述车辆服务包括至少两个服务层级；根据所述调用请求，生成每个所述服务层级的调用关系；根据所述调用关系获取对应的所述服务层级的实际调用次数和实际被调用次数；根据所述实际调用次数和所述实际被调用次数以及预设的服务调用规则对各个所述服务层级进行监控，以判断所述服务层级是否存在异常。2.根据权利要求1所述的方法，其特征在于，根据所述实际调用次数和所述实际被调用次数以及预设的服务调用规则对各个所述服务层级进行监控，以判断所述服务层级是否存在异常，包括：获取所述服务调用规则，其中，所述服务调用规则至少包括异常判断规则，以及每个调用请求中每个所述服务层级的理论调用次数和理论被调用次数；根据所述实际调用次数、所述实际被调用次数、所述理论调用次数、所述理论被调用次数和所述异常判断规则判断各个所述服务层级是否存在异常。3.根据权利要求2所述的方法，其特征在于，所述服务层级存在异常包括调用方异常、被调用方异常和设计异常，根据所述实际调用次数、所述实际被调用次数、所述理论调用次数、所述理论被调用次数和所述异常判断规则判断各个所述服务层级是否存在异常，包括：在一组调用关系中，一个调度周期内所述服务层级作为调用方发起的理论调用次数为一次，若所述服务层级发起的所述实际调用次数大于所述理论调用次数，则判断所述服务层级存在调用方异常；在一组调用关系中，一个调度周期内所述服务层级作为被调用方的所述实际被调用次数小于所述理论被调用次数，则判断所述服务层级存在被调用方异常；在一组调用关系中，一个调度周期内所述服务层级作为被调用方的所述实际被调用次数大于所述理论被调用次数，则判断所述服务层级存在设计异常。4.根据权利要求1所述的方法，其特征在于，获取车辆服务的调用请求之前，所述方法还包括：为每一个所述服务层级配置标识信息，所述标识信息用于指示所述服务层级；相应地，所述调用关系携带调用方的所述标识信息和被调用方的所述标识信息。5.根据权利要求1所述的方法，其特征在于，根据所述调用次数和所述被调用次数以及预设的服务调用规则对各个所述服务层级进行监控，以判断所述服务层级是否存在异常之后，所述方法还包括：获取出现异常的服务层级的参数信息；其中，所述参数信息至少包括服务层级标识、异常类型和异常发生时间；将所述参数信息发送到日志存储模块进行本地存储，和/或，发送到日志上传模块进行云端存储，以使本地和/或云端根据所述参数信息定位异常服务。6.根据权利要求1所述的方法，其特征在于，所述服务层级包括场景服务层、系统服务层、增强服务层、原子服务层、输入输出抽象层和基础服务层；其中，所述场景服务层允许被外部调用；所述系统服务层允许被所述场景服务层调用；所述增强服务层允许被所述系统服务层调用；
所述原子服务层允许被所述增强服务层调用；所述输入输出抽象层允许被所述原子服务层调用；所述基础服务层允许被所述场景服务层、所述系统服务层、所述增强服务层、所述原子服务层调用。7.一种车辆服务监控系统，其特征在于，所述系统包括：服务监控模块、处理模块和日志模块；所述服务监控模块，用于获取车辆服务的调用请求；其中，所述车辆服务包括至少两个服务层级；根据所述调用请求，生成每个所述服务层级的调用关系；所述处理模块，用于根据所述调用关系获取对应的所述服务层级的实际调用次数和实际被调用次数；根据所述实际调用次数和所述实际被调用次数以及预设的服务调用规则对各个所述服务层级进行监控，以判断所述服务层级是否存在异常，并将异常的所述服务层级的参数信息发送至所述日志模块存储。8.一种车辆服务监控装置，其特征在于，所述装置包括：第一获取模块，用于获取车辆服务的调用请求；其中，所述车辆服务包括至少两个服务层级；生成模块，用于根据所述调用请求，生成每个所述服务层级的调用关系；第二获取模块，用于根据所述调用关系获取对应的所述服务层级的实际调用次数和实际被调用次数；监控判断模块，用于根据所述实际调用次数和所述实际被调用次数以及预设的服务调用规则对各个所述服务层级进行监控，以判断所述服务层级是否存在异常。9.一种电子装置，其特征在于，包括处理器、通信接口、存储器和通信总线，其中，处理器，通信接口，存储器通过通信总线完成相互间的通信；存储器，用于存放计算机程序；处理器，用于执行存储器上所存放的程序时，实现权利要求1-6任一所述的方法。10.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质内存储有计算机程序，所述计算机程序被处理器执行时实现权利要求1-6任一所述的方法。

技术总结
本申请涉及一种车辆服务监控方法、装置、系统及存储介质，方法包括：获取车辆服务的调用请求；其中，车辆服务包括至少两个服务层级；根据调用请求，生成每个服务层级的调用关系；根据调用关系获取对应的服务层级的实际调用次数和实际被调用次数；根据实际调用次数和实际被调用次数以及预设的服务调用规则对各个服务层级进行监控。本申请可以根据调用请求，生成每个服务层级的调用关系，并进一步获取每个服务层级的实际调用次数和实际被调用次数，从而可以根据调用次数是否符合预设的服务调用规则对各个服务层级进行监控，并对调用次数异常的服务层级进行精准定位，可快捷高效的解决功能异常时的定位问题，提高了故障处理的效率。率。率。


技术研发人员：郑淋荣
受保护的技术使用者：重庆长安汽车股份有限公司
技术研发日：2023.06.13
技术公布日：2023/8/28