Monitoring result determination method and device, storage medium and electronic device

Abstract

The invention discloses a monitoring result determination method and device, a storage medium and an electronic device.The method comprises the steps that under the condition that a monitoring module is deployed in middleware of a vehicle, a configuration rule is sent to other modules in the middleware; receiving reported data fed back by the other modules based on the configuration rule; and determining a monitoring result of the middleware through the reported data. The problem that a monitoring scheme for the middleware of the automatic driving and intelligent network connection automobile is lacked in the related technology is solved. The technical effect of accurately recognizing the road scene is achieved. And an efficient monitoring scheme for the middleware of the automatic driving and intelligent connected automobile is provided.

Description

Technical Field

[0001] The present application relates to the vehicle-mounted field, and more specifically, to a method and device for determining monitoring results, a storage medium, and an electronic device. Background Art

[0002] There is middleware (Adaptive Platform, referred to as AP) in autonomous driving and intelligent connected cars. As operating system middleware, this middleware is responsible for providing service interface and function interface capabilities for AA (application). However, in the relevant technology, there is a lack of monitoring solutions for this middleware.

[0003] There is no effective solution to the problem of lack of monitoring solutions for middleware of autonomous driving and intelligent connected vehicles in related technologies. Summary of the invention

[0004] The embodiments of the present application provide a method and device for determining monitoring results, a storage medium, and an electronic device, so as to at least solve the problem of the lack of monitoring solutions for middleware of autonomous driving and intelligent connected vehicles in the related technology.

[0005] According to one aspect of an embodiment of the present application, a method for determining monitoring results is provided, comprising: when a monitoring module is deployed in the middleware of a vehicle, sending configuration rules to other modules in the middleware; receiving reported data fed back by the other modules based on the configuration rules; and determining the monitoring results of the middleware through the reported data.

[0006] In an exemplary embodiment, sending configuration rules to other modules in the middleware includes: determining a node attribute of the monitoring module in a preset cluster, wherein the preset cluster includes multiple monitoring modules corresponding to multiple different domains of the vehicle, the multiple monitoring modules include the monitoring module, and the multiple different domains correspond one-to-one to the multiple monitoring modules; when the node attribute is a first attribute, sending the first rule deployed in the monitoring module as the configuration rule to the other modules; when the node attribute is a second attribute, sending the second rule received by the monitoring module from a target monitoring module having the first attribute to the other modules, wherein the multiple monitoring modules include: the target monitoring module.

[0007] In an exemplary embodiment, before sending configuration rules to other modules in the middleware, the method also includes: receiving a configuration file written in a preset configuration manner; when the configuration file records a first configuration, determining that the node attribute of the monitoring node is the first attribute; when the configuration file records a second configuration, determining that the node attribute of the monitoring node is the second attribute.

[0008] In an exemplary embodiment, the monitoring result of the middleware is determined through the reported data, including: when the node attribute of the monitoring module is the second attribute, performing a first processing operation on the reported data to obtain first summary data; sending the first summary data to the target monitoring module, and determining the monitoring result of the middleware through the first summary data.

[0009] In an exemplary embodiment, the monitoring result of the middleware is determined through the reported data, including: when the node attribute of the monitoring module is the first attribute, performing a first processing operation on the reported data to obtain second summary data; and receiving the first summary data reported by other monitoring modules among the multiple monitoring modules except the target monitoring module; performing a second processing operation on the first summary data and the second summary data to obtain third summary data; and determining the monitoring results of the middleware corresponding to the multiple different domains respectively through the third summary data.

[0010] In an exemplary embodiment, sending configuration rules to other modules in the middleware includes: sending the configuration rules to the other modules when the monitoring module is started; and sending the configuration rules to the other modules according to the configuration request sent by the other modules when the monitoring module has been started and the other modules have not received the configuration rules.

[0011] In an exemplary embodiment, receiving the reported data fed back by the other modules based on the configuration rules includes: determining the number of data groups of the reported data received within the current time interval; if the number of data groups meets the number of modules of the other modules, determining that the reported data required to be received within the current time period has been received; and if the number of data groups does not meet the number of modules of the other modules, executing a first alarm event.

[0012] According to another aspect of an embodiment of the present application, a device for determining monitoring results is also provided, including: a sending module, used to send configuration rules to other modules in the middleware of a vehicle when a monitoring module is deployed in the middleware; a receiving module, used to receive reported data fed back by the other modules based on the configuration rules; and a determination module, used to determine the monitoring results of the middleware through the reported data.

[0013] According to another aspect of an embodiment of the present application, a computer-readable storage medium is further provided, characterized in that the computer-readable storage medium includes a stored program, wherein the program executes the above-mentioned method for determining monitoring results when it is executed.

[0014] According to another aspect of an embodiment of the present application, there is further provided an electronic device, including a memory and a processor, wherein a computer program is stored in the memory, and the processor runs the above-mentioned method for determining monitoring results through the computer program.

[0015] According to another aspect of the embodiments of the present application, a computer program product is provided, including a computer program, and when the computer program is executed by a processor, the method for determining the monitoring result is implemented.

[0016] In an embodiment of the present application, when a monitoring module is deployed in the vehicle's middleware, configuration rules are sent to other modules in the middleware; reported data fed back by the other modules based on the configuration rules is received; and the monitoring results of the middleware are determined by the reported data. In other words, by deploying a monitoring module in the middleware, and then using the monitoring module to send configuration rules, receive reported data, and determine monitoring results for other modules in the middleware, the problem of the lack of monitoring solutions for middleware of autonomous driving and intelligent networked vehicles in related technologies is solved. An efficient monitoring solution for middleware of autonomous driving and intelligent networked vehicles is provided. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] The drawings described herein are used to provide a further understanding of the present application and constitute a part of the present application. The illustrative embodiments of the present application and their descriptions are used to explain the present application and do not constitute an improper limitation on the present application. In the drawings:

[0018] Figure 1 It is a hardware structure block diagram of a computer terminal according to a method for determining a monitoring result in an embodiment of the present application;

[0019] Figure 2 is a flow chart of a method for determining monitoring results according to an embodiment of the present application;

[0020] Figure 3 is a schematic diagram of an AP classic framework of a method for determining a monitoring result according to an embodiment of the present application;

[0021] Figure 4 is a schematic diagram of a new AP framework of a method for determining monitoring results according to an embodiment of the present application;

[0022] Figure 5 is a schematic diagram of the interaction between a monitoring module and other modules of a method for determining monitoring results according to an embodiment of the present application;

[0023] Figure 6 is a schematic diagram of inter-cluster communication according to a method for determining a monitoring result according to an embodiment of the present application;

[0024] Figure 7 is another flow chart of a method for determining a monitoring result according to an embodiment of the present application;

[0025] Figure 8 is another flow chart of a method for determining a monitoring result according to an embodiment of the present application;

[0026] Fig. 9 It is a structural block diagram of a device for determining monitoring results according to an embodiment of the present application. DETAILED DESCRIPTION

[0027] In order to enable those skilled in the art to better understand the solution of the present application, the technical solution in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without creative work should fall within the scope of protection of the present application.

[0028] It should be noted that the terms "first", "second", etc. in the specification and claims of the present application and the above-mentioned drawings are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence. It should be understood that the data used in this way can be interchangeable where appropriate, so that the embodiments of the present application described herein can be implemented in an order other than those illustrated or described herein. In addition, the terms "including" and "having" and any of their variations are intended to cover non-exclusive inclusions, for example, a process, method, system, product or device comprising a series of steps or units is not necessarily limited to those steps or units clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products or devices.

[0029] The method embodiment provided in the embodiment of the present application can be run in a computer terminal. Taking running on a computer terminal as an example, Figure 1 1 is a hardware structure block diagram of a computer terminal according to a method for determining monitoring results in an embodiment of the present application. Figure 1 As shown, the computer terminal may include one or more ( Figure 1 Only one is shown in the figure) processor 102 (processor 102 may include but is not limited to a processing system such as a microprocessor MCU or a programmable logic device FPGA) and a memory 104 for storing data. In an exemplary embodiment, the computer terminal may also include a transmission device 106 and an input / output device 108 for communication functions. It can be understood by those skilled in the art that Figure 1 The structure shown is only for illustration and does not limit the structure of the above-mentioned computer terminal. Figure 1 More or fewer components as shown, or with Figure 1 Equivalent functions or comparisons shown Figure 1 A different configuration with more features is shown.

[0030] The memory 104 can be used to store computer programs, for example, software programs and modules of application software, such as the computer program corresponding to the method for determining the monitoring results in the embodiment of the present application. The processor 102 runs various functional applications and data processing by running the computer program stored in the memory 104, that is, to implement the above method. The memory 104 may include a high-speed random access memory, and may also include a non-volatile memory, such as one or more magnetic storage systems, flash memory, or other non-volatile solid-state memory. In some instances, the memory 104 may further include a memory remotely arranged relative to the processor 102, and these remote memories may be connected to the secure text via a network. Examples of the above-mentioned network include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.

[0031] The transmission device 106 is used to receive or send data via a network. The specific example of the above network may include a wireless network provided by a communication provider of the camera device. In one example, the transmission system 106 includes a network adapter (Network Interface Controller, referred to as NIC), which can be connected to other network devices through a base station so as to communicate with the Internet.

[0032] In this embodiment, a method for determining a monitoring result is provided, including but not limited to middleware applied to the above-mentioned computer terminal, autonomous driving, and intelligent networked vehicles, etc. Figure 2 : is a flow chart of a method for determining a monitoring result according to an embodiment of the present application, the process comprising the following steps:

[0033] Step S202, when a monitoring module is deployed in the vehicle's middleware, sending configuration rules to other modules in the middleware;

[0034] It should be noted that the middleware AP for autonomous driving and intelligent connected vehicles is a highly modular software architecture that supports different functions and services. The typical architecture of the middleware AP is as follows: Figure 3 As shown, it includes an application (Application, referred to as APP), an operating system (Operating System, referred to as OS), and other modules deployed between the application and the operating system and capable of interacting with the application and the operating system;

[0035] The other modules are: COM (Communication Management) module responsible for communication between applications; TS (Time Synchronization) module providing time synchronization function; Core; LT (Log and Trace) module responsible for recording AP AUTOSAR logs; PER (Persistency) module providing a mechanism for AP applications and other AP modules to store information in the non-volatile memory of the Adaptive Machine, and providing a standard interface for accessing non-volatile memory; SM (State Management) module responsible for all aspects of AP operating status, such as processing incoming events, setting corresponding status, etc.; EM (Execution Management) module used for platform lifecycle management and application lifecycle management; OSL module (Operating System Interface) OSL module, etc.

[0036] Further, such as Figure 4 As shown, the embodiment of the present application additionally deploys a monitoring module (equivalent to Figure 4 The MONITOR in the module is used to execute monitoring operations such as issuing configuration rules and receiving reported data on the other modules mentioned above, thereby realizing the monitoring of the middleware of autonomous driving and intelligent connected vehicles.

[0037] Step S204, receiving the reported data fed back by the other modules based on the configuration rules;

[0038] Step S206: determining the monitoring result of the middleware through the reported data.

[0039] Through the above steps, when a monitoring module is deployed in the vehicle's middleware, configuration rules are sent to other modules in the middleware; reported data fed back by the other modules based on the configuration rules are received; and the monitoring results of the middleware are determined through the reported data. In other words, by deploying a monitoring module in the middleware, and then using the monitoring module to send configuration rules, receive reported data, and determine monitoring results for other modules in the middleware, the problem of the lack of monitoring solutions for middleware of autonomous driving and intelligent networked vehicles in related technologies is solved. An efficient monitoring solution for middleware of autonomous driving and intelligent networked vehicles is provided.

[0040] There are multiple implementation methods for the above-mentioned step S202. In one implementation method, sending configuration rules to other modules in the middleware includes: determining the node attribute of the monitoring module in a preset cluster, wherein the preset cluster includes multiple monitoring modules corresponding to multiple different domains of the vehicle, the multiple monitoring modules include the monitoring module, and the multiple different domains correspond one-to-one to the multiple monitoring modules; when the node attribute is a first attribute, sending the first rule deployed in the monitoring module as the configuration rule to the other modules; when the node attribute is a second attribute, sending the second rule received by the monitoring module from the target monitoring module having the first attribute to the other modules, wherein the multiple monitoring modules include: the target monitoring module.

[0041] The monitoring module in the embodiment of the present application can realize cross-domain monitoring. Cross-domain means that middleware APs are deployed in multiple different domains of the car, such as the intelligent driving domain, the control domain, etc., and the middleware APs in each different domain are deployed with monitoring modules. Furthermore, the preset cluster in the above embodiment can be understood as a monitoring module cluster. There are master nodes (master) and slave nodes (slave) in the preset cluster. Specifically, there is only one master node, and all nodes except the master node are slave nodes.

[0042] Multiple monitoring modules in the entire preset cluster can all be configured by the target object rules (such as the first rule and the second rule in the above embodiment), but only the rules configured for the master node can be used as configuration rules that are sent down layer by layer to other modules in the middleware in each different domain. Therefore, in the embodiment of the present application, the monitoring module needs to determine the node attribute of the monitoring module in the process of sending down the configuration rules. When the node attribute is the master node (i.e., the first attribute), the first rule deployed in the monitoring module can be sent down as a configuration rule to other modules; when the node attribute is the slave node (i.e., the second attribute), the second rule received by the monitoring module from the target monitoring module having the first attribute can be sent to the other modules as a configuration rule.

[0043] Therefore, the embodiment of the present application realizes layered monitoring of different middleware in multiple different domains of a car by deploying a monitoring module cluster.

[0044] Furthermore, before sending configuration rules to other modules in the middleware, the method also includes: receiving a configuration file written in a preset configuration manner; when the configuration file records a first configuration, determining that the node attribute of the monitoring node is the first attribute; when the configuration file records a second configuration, determining that the node attribute of the monitoring node is the second attribute.

[0045] It should be noted that the preset configuration mode is a json configuration mode, and the node attributes of the monitoring module can be determined from the configuration file received by the monitoring module. Optionally, the first configuration can be:

[0046] monitor_rules.json

[0047] Master Configuration

[0048] {

[0049] "role": "master"

[0050] }

[0051] Optionally, the second configuration may be:

[0052] Slave Configuration

[0053] {

[0054] “role”: “slave”

[0055] }

[0056] Therefore, in the embodiment of the present application, the monitoring module can determine the node attributes of the monitoring module according to the pre-configured configuration file, so as to clarify how to send configuration rules to other modules in the middleware.

[0057] In an exemplary embodiment, sending configuration rules to other modules in the middleware includes: sending the configuration rules to the other modules when the monitoring module is started; and sending the configuration rules to the other modules according to the configuration request sent by the other modules when the monitoring module has been started and the other modules have not received the configuration rules.

[0058] In the process of issuing configuration rules, there are two situations: active issuance and passive issuance. For active issuance, after the monitoring module is started, the monitoring module will actively issue configuration rules to other modules. For passive issuance, after other modules are started, if they do not receive active configuration, they will actively register and initiate a configuration request to the monitoring module to trigger the monitoring module to passively issue configuration rules. It should be noted that all modules in the middleware except the monitoring module include the other modules, that is, the monitoring module can be configured to monitor all modules in the middleware or some modules in all modules. Therefore, by actively issuing and passively issuing configuration rules, all modules that need to be monitored in the middleware can be issued with configuration rules.

[0059] In an exemplary embodiment, receiving the reported data fed back by the other modules based on the configuration rules includes: determining the number of data groups of the reported data received within the current time interval; if the number of data groups meets the number of modules of the other modules, determining that the reported data required to be received within the current time period has been received; and if the number of data groups does not meet the number of modules of the other modules, executing a first alarm event.

[0060] Optionally, in an embodiment of the present application, other modules feed back reported data to the monitoring module at a preset frequency, and the reported data of other modules needs to be completely received within the current time interval. If it is not completely received, a first alarm event can be executed to indicate that the target other module corresponding to the actual set of reported data may have a fault. Among them, the current time interval is the time interval in which the monitoring module of the current round is allowed to receive reported data, and the interval length of the current time interval is equal to the length of the time interval corresponding to the preset frequency.

[0061] In an exemplary embodiment, the monitoring result of the middleware is determined through the reported data, including: when the node attribute of the monitoring module is the second attribute, performing a first processing operation on the reported data to obtain first summary data; sending the first summary data to the target monitoring module, and determining the monitoring result of the middleware through the first summary data.

[0062] It should be noted that other modules will filter and process their own data according to the configuration rules to obtain reported data. The monitoring module summarizes and filters the reported data received from other modules twice (the first processing operation includes the summarization and secondary filtering) to obtain first summarized data. Furthermore, if the node attribute of the monitoring module is a slave node, the monitoring module can directly analyze the first summarized data, and continue to report the first summarized data to the target monitoring module with the first attribute in the preset cluster.

[0063] Optionally, the monitoring result of the middleware is determined through the reported data, including: when the node attribute of the monitoring module is the first attribute, performing a first processing operation on the reported data to obtain second summary data; and receiving the first summary data reported by other monitoring modules among the multiple monitoring modules except the target monitoring module; performing a second processing operation on the first summary data and the second summary data to obtain third summary data; and determining the monitoring results of the middleware corresponding to the multiple different domains respectively through the third summary data.

[0064] It should be noted that the first summary data is the summary data of the monitoring module whose node attribute is a slave node, and the second summary data is the summary data of the monitoring module whose node attribute is a master node.

[0065] The monitoring module of the node attribute master node, that is, the target monitoring module analyzes its own second summary data and the first summary data received from other monitoring modules, filters and summarizes them again, and then forms a report and issues abnormal alarms.

[0066] In order to better understand the above-mentioned scheme for determining the monitoring results, in an optional embodiment, a scheme is also provided to explain the above-mentioned scheme.

[0067] There is a lack of standard definition of module monitoring in AUTOSAR AP. Therefore, the optional embodiment of this application proposes a method for implementing a cross-domain AP fault diagnosis and monitoring mechanism, which is mainly used in middleware APs for autonomous driving and intelligent connected vehicles. Specifically, the optional embodiment of this application introduces a new module Monitor to perform cross-domain (cross-domain means that AP software is deployed in multiple different domains, such as intelligent driving domain, control domain, etc.) process monitoring and diagnosis of AP and related applications, including but not limited to abnormal data analysis, variable status monitoring, abnormal logical behavior alarm, resource occupancy threshold alarm and other operations.

[0068] Figure 3 The typical architecture of AP is demonstrated. As the operating system middleware, AP is responsible for providing service interface and functional interface capabilities to AA (application). Figure 3 The main AP modules are listed in (please refer to the AP-AUTOSAR standard for details).

[0069] The AP-AUTOSAR standard definition does not define the industry standard for the Monitor module. The optional embodiment of this application introduces the diagnosis and monitoring capabilities for the AP module and application (APP). Figure 4 As shown, a Monitor module is introduced into the AP. It should be noted that the Monitor, the Monitor module or the Monitor module in the optional embodiment of the present application is equivalent to the monitoring module in the above embodiment.

[0070] Figure 4 The main function of the Monitor module in the AP module is to monitor and diagnose relevant indicators of the AP module and application, including but not limited to abnormal data analysis, variable status monitoring, abnormal logic behavior alarm, resource usage threshold alarm, etc.

[0071] based on Figure 4 The architecture shown, further, Figure 5 Shows the brief interaction between Monitor and other modules in AP. Figure 5It can be seen that Monitor interacts with AP modules and applications, mainly including data analysis, variable status monitoring, logical behavior monitoring, resource usage threshold monitoring, etc.

[0072] Optionally, the interaction between a Monitor and other Monitors (equivalent to multiple monitoring modules corresponding to multiple different domains in the above embodiment) mainly includes two types: Master and Slave role selection information interaction and analysis data reporting interaction. Figure 6 The Monitor cluster (equivalent to the preset cluster in the above embodiment) solution is shown (not limited to the number of deployments in the optional embodiment of the present application), that is, a new AP architecture corresponding to multiple different domains is shown (such as Figure 4 The interactive relationship between the two is shown in the figure. The Monitor cluster deployment is mainly to solve the problems of cross-domain monitoring diagnosis, centralized data analysis, multi-point reference linkage diagnosis, centralized data display, and simplified monitoring process. Figure 6 The following information is included:

[0073] 1) Compatible with other module deployment behaviors of AP platform.

[0074] 2) Only one set of Monitor is deployed in each domain (that is, each different domain in multiple different domains).

[0075] 3) Monitors in the Monitor cluster communicate with each other using Ethernet and TCP / UDP.

[0076] 4) Shared memory is used for communication between Monitor and AP modules in each different domain.

[0077] 5) The Monitor role is configured with two identities: Master and Slave. There is only one Master.

[0078] 6) Support online update of Monitor nodes including adding, deleting and other operations.

[0079] 7) Monitor performs local calculations and reports the abnormal data to the Master.

[0080] Figure 7 The Monitor data reporting flow chart within the domain (i.e. within each different domain) is shown. The chart is divided into two parts: configuration delivery and data reporting.

[0081] The configuration delivery process is divided into two parts, active delivery and passive delivery. Active delivery will trigger the active delivery configuration (i.e., configuration rules) process after the Monitor is started. If the AP module (equivalent to other modules in the above embodiment) does not receive active delivery configuration after startup, it will actively register and initiate a configuration delivery request to trigger the Monitor's passive configuration delivery. (The purpose of delivering the configuration is to enable the required monitoring rules, which is used for the module to select which information needs to be reported to the Monitor for processing).

[0082] The data reporting process filters the content to be reported according to the issued rules (equivalent to the configuration rules in the above embodiment) and reports it to the Monitor (the reported content is the reporting data in the above embodiment).

[0083] It should be noted that the intra-domain and inter-domain interfaces can be implemented using the Someip / DDS configuration service interface, and the specific interface configuration can be configured using the AP tool chain to generate the service framework code. How to configure the interface through the tool chain tool is not described in detail in the optional embodiment of this application. Please refer to the relevant specification description of the tool chain in AP AUTOSAR.

[0084] against Figure 7 It should also be noted that notify config: notification configuration, indicating that the monitoring module actively sends configuration rules to other modules. request: request, indicating requesting a certain operation or information from the system or user, and in the optional embodiment of the present application, indicating issuing a configuration request. send config: send configuration, in the optional embodiment of the present application, indicating that the monitoring module passively sends configuration rules to other modules according to the issued configuration request. data report: data report, indicating that other modules feed back reported data to the monitoring module.

[0085] More specifically, Monitor proactively configures the delivery process:

[0086] notify config actively sends configuration via event

[0087] The AP module and other applications that need to be monitored (equivalent to other modules in the above embodiment) receive the configuration rules and store them in the cache.

[0088] Monitor passive configuration delivery process:

[0089] When the AP module and other applications that need to be monitored are started later than the Monitor, they need to actively request the Monitor module and trigger the Monitor passive configuration delivery process. Specifically:

[0090] The Monitor module receives the request and replies with a send config message;

[0091] The AP module and other applications that need to be monitored receive the configuration rules and store them in the cache.

[0092] Monitor data reporting process:

[0093] The AP module and other applications that need to be monitored first filter the data that needs to be reported according to the stored configuration rules and then actively report the data information to the Monitor (data report).

[0094] The monitor configuration update process is the same as the monitor active delivery process, including:

[0095] AP modules and other applications that need to be monitored are based on the stored configuration rules. When an update is required, the update process can be triggered and the notify config interface can be sent to all AP modules and applications through multicast.

[0096] Furthermore, Figure 8 The inter-domain Monitor data reporting process is shown, which is similar to the intra-domain reporting process, but the difference lies in the difference in reported data. The data reported within the domain is the data reported by each application and AP process that needs to be monitored according to the configuration filtering, while the data reported by the inter-domain Monitor is the information calculated by the Monitor in each domain. Monitor is divided into two types: Slave Monitor and Master Monitor in different domains, of which there is only one Master Monitor. The SlaveMonitor is responsible for receiving the configuration issued by the Master Monitor (equivalent to the second rule in the above embodiment, including: monitoring rules, filtering rules) and then configuring the received configuration rules in the domain and sending them to each application and AP process that needs to be monitored. The Master Monitor summarizes the information reported by all Slave Monitors (equivalent to the first summary data and the second summary data in the above embodiment) to generate alarm or report information. The above cross-domain process communication still uses the service configured by someip / dds, and the configuration interface is consistent with the intra-domain interface, but different services need to be started for support.

[0097] Optionally, the Monitor configuration file determines whether the monitoring module is a master or a slave:

[0098] When configuring a Monitor cluster, you need to specify the Monitor role. There is only one master in the Monitor cluster. The design uses the json configuration method, as follows:

[0099] monitor_rules.json

[0100] Master Configuration

[0101] {

[0102] "role": "master"

[0103] }

[0104] Slave Configuration

[0105] {

[0106] “role”: “slave”

[0107] }

[0108] For example, adding rule configuration (i.e., configuration rules) in the Master Monitor may include but is not limited to the following:

[0109] {

[0110] "rules":[

[0111] {

[0112] "type":"fuzzy",

[0113] "keyword":"error",

[0114] "alert_threshold":5,

[0115] "data_type":"log"

[0116] },

[0117] {

[0118] "type":"exact",

[0119] "metric":"response_time",

[0120] "threshold":100,

[0121] "alert_threshold":150,

[0122] "data_type":"performance"

[0123] } ]

[0125] }

[0126] The following is an explanation of the above rule configuration code:

[0127] The first rule is a fuzzy matching rule:

[0128] type: The rule type is fuzzy matching.

[0129] keyword: The keyword is "error", which means that all data containing the keyword "error" must be filtered out.

[0130] alert_threshold: The alarm threshold is 5, which means that an alarm is triggered when the number of data that meets the rule reaches or exceeds 5.

[0131] data_type: The data collection type is "log", which means that the data is log data. Such a rule is suitable for monitoring error information in the system log and triggering an alarm when the number of errors exceeds the threshold.

[0132] The second rule is an exact match rule:

[0133] type: The rule type is exact match.

[0134] metric: specifies the collection metric type as "response_time", that is, response time.

[0135] threshold: Set the threshold to 100, which means that only responses with a response time greater than or equal to 100 milliseconds will pass the filter.

[0136] alert_threshold: The alarm threshold is 150, which means that an alarm is triggered when the response time exceeds 150 milliseconds.

[0137] data_type: The data collection type is "performance", which means that the data is performance data. Such rules can help monitor system performance and trigger alarms when thresholds are exceeded.

[0138] It should be noted that the code shown in the above rule configuration is only one of the descriptions of the rule configuration. The relevant configuration items can be expanded to add monitoring configurations of other indicators. In addition, regular expressions can also be used in the filtering conditions.

[0139] Therefore, the optional embodiment of the present application realizes the monitoring of middleware in multiple different domains and other modules in the middleware in each different domain by introducing the AP module and the applied abnormal monitoring module Monitor, and can realize the analysis of abnormal data reported by other modules, including cross-domain multi-module data integration analysis; it can realize resource threshold monitoring, including but not limited to cpu, memory, io and other resources, and can realize internal operation status monitoring of modules (such as other modules in the above embodiments), including program variables and memory state machines, etc.; it can realize abnormal analysis reporting and alarm reporting; it can realize Monitor cross-domain communication protocol, including data transmission and Master, Slave role selection; it can realize Monitor dynamic support, including operations such as adding and deleting Monitor nodes; it can support adding Monitor local configuration items to realize configurable required monitoring data; and it can also add some Monitor commands in real time to display the required monitoring data information in real time.

[0140] In summary, the optional embodiments of this application are intended to improve the existing AP-AUTOSAR specifications and introduce the Monitor module to increase monitoring and data analysis capabilities for AP modules and applications. This enables AP modules and applications to have self-diagnosis and troubleshooting capabilities, and enhances the security and stability of AP software through joint data analysis, fault location, risk data warning and other technical means, and reduces corresponding other software risks.

[0141] Through the description of the above implementation methods, those skilled in the art can clearly understand that the method according to the above embodiment can be implemented by means of software plus a necessary general hardware platform, and of course by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of the present application, or the part that contributes to the prior art, can be embodied in the form of a software product, which is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk), and includes a number of instructions for a terminal device (which can be a mobile phone, computer, server, or network device, etc.) to run the methods of each embodiment of the present application.

[0142] In the present embodiment, a device for determining monitoring results is also provided, which is used to implement the above-mentioned embodiments and preferred implementation modes, and the descriptions thereof will not be repeated. As used below, the term "module" can implement a combination of software and / or hardware of a predetermined function. Although the equipment described in the following embodiments is preferably implemented in software, the implementation of hardware, or a combination of software and hardware, is also possible and contemplated.

[0143] Fig. 9 is a structural block diagram of a device for determining monitoring results according to an embodiment of the present application; Fig. 9As shown, including:

[0144] A sending module 92, used for sending configuration rules to other modules in the middleware when a monitoring module is deployed in the middleware of the vehicle;

[0145] A receiving module 94, configured to receive the reported data fed back by the other modules based on the configuration rules;

[0146] The determination module 96 is used to determine the monitoring result of the middleware according to the reported data.

[0147] Through the above-mentioned device of the present application, when a monitoring module is deployed in the middleware of the vehicle, configuration rules are sent to other modules in the middleware; reported data fed back by the other modules based on the configuration rules are received; and the monitoring results of the middleware are determined by the reported data. In other words, by deploying a monitoring module in the middleware, and then using the monitoring module to send configuration rules, receive reported data, and determine monitoring results for other modules in the middleware, the problem of the lack of monitoring solutions for middleware of autonomous driving and intelligent networked vehicles in related technologies is solved. An efficient monitoring solution for middleware of autonomous driving and intelligent networked vehicles is provided.

[0148] In an exemplary embodiment, the sending module 92 is also used to: determine the node attribute of the monitoring module in a preset cluster, wherein the preset cluster includes multiple monitoring modules corresponding to multiple different domains of the vehicle, the multiple monitoring modules include the monitoring module, and the multiple different domains correspond one-to-one to the multiple monitoring modules; when the node attribute is a first attribute, the first rule deployed in the monitoring module is sent to the other modules as the configuration rule; when the node attribute is a second attribute, the second rule received by the monitoring module from the target monitoring module having the first attribute is sent to the other modules, wherein the multiple monitoring modules include: the target monitoring module.

[0149] In an exemplary embodiment, before sending configuration rules to other modules in the middleware, the sending module 92 is also used to: receive a configuration file written in a preset configuration manner; when the configuration file records a first configuration, determine that the node attribute of the monitoring node is the first attribute; when the configuration file records a second configuration, determine that the node attribute of the monitoring node is the second attribute.

[0150] In an exemplary embodiment, the determination module 96 is also used to: when the node attribute of the monitoring module is the second attribute, perform a first processing operation on the reported data to obtain first summary data; send the first summary data to the target monitoring module, and determine the monitoring result of the middleware through the first summary data.

[0151] In an exemplary embodiment, the determination module 96 is also used to: when the node attribute of the monitoring module is the first attribute, perform a first processing operation on the reported data to obtain second summary data; and receive the first summary data reported by other monitoring modules among the multiple monitoring modules except the target monitoring module; perform a second processing operation on the first summary data and the second summary data to obtain third summary data; and determine the monitoring results of the middleware corresponding to the multiple different domains respectively through the third summary data.

[0152] In an exemplary embodiment, the sending module 92 is also used to: when the monitoring module is started, send the configuration rules to the other modules; when the monitoring module has been started and the other modules have not received the configuration rules, send the configuration rules to the other modules according to the configuration request sent by the other modules.

[0153] In an exemplary embodiment, the receiving module 94 is also used to: determine the number of data groups of the reported data received within the current time interval; when the number of data groups meets the number of modules of the other modules, determine that the reported data required to be received within the current time period has been received; and when the number of data groups does not meet the number of modules of the other modules, execute the first alarm event.

[0154] An embodiment of the present application further provides a storage medium, which includes a stored program, wherein when the program is executed, any of the above methods is executed.

[0155] Optionally, in this embodiment, the storage medium may be configured to store program codes for executing the following steps:

[0156] S1, when a monitoring module is deployed in the vehicle's middleware, sending configuration rules to other modules in the middleware;

[0157] S2, receiving the reported data fed back by the other modules based on the configuration rules;

[0158] S3: Determine the monitoring result of the middleware according to the reported data.

[0159] In an exemplary embodiment, the computer-readable storage medium may include, but is not limited to, various media that can store computer programs, such as a USB flash drive, a read-only memory (ROM), a random access memory (RAM), a mobile hard disk, a magnetic disk or an optical disk.

[0160] For specific examples in this embodiment, reference may be made to the examples described in the above embodiments and exemplary implementation modes, and this embodiment will not be described in detail herein.

[0161] An embodiment of the present application further provides an electronic device, including a memory and a processor, wherein a computer program is stored in the memory, and the processor is configured to execute the computer program to execute the steps in any one of the above method embodiments.

[0162] Optionally, in this embodiment, the processor may be configured to execute the following steps through a computer program:

[0163] S1, when a monitoring module is deployed in the vehicle's middleware, sending configuration rules to other modules in the middleware;

[0164] S2, receiving the reported data fed back by the other modules based on the configuration rules;

[0165] S3: Determine the monitoring result of the middleware according to the reported data.

[0166] Optionally, the electronic device may further include a transmission device and an input / output device, wherein the transmission device is connected to the processor, and the input / output device is connected to the processor.

[0167] An embodiment of the present application further provides a computer program product, which includes a computer program. When the computer program is executed by a processor, the steps in any one of the above method embodiments are implemented.

[0168] Optionally, in this embodiment, the computer program product may be configured to perform the following steps through a computer program:

[0169] S1, when a monitoring module is deployed in the vehicle's middleware, sending configuration rules to other modules in the middleware;

[0170] S2, receiving the reported data fed back by the other modules based on the configuration rules;

[0171] S3: Determine the monitoring result of the middleware according to the reported data.

[0172] An embodiment of the present application further provides another computer program product, including a non-volatile computer-readable storage medium, wherein the non-volatile computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the steps in any of the above method embodiments are implemented.

[0173] An embodiment of the present application also provides a computer program, which includes computer instructions stored in a computer-readable storage medium; a processor of a computer device reads the computer instructions from the computer-readable storage medium, and the processor executes the computer instructions, so that the computer device performs the steps in any one of the above method embodiments.

[0174] Optionally, the specific examples in this embodiment may refer to the examples described in the above embodiments and optional implementation modes, and this embodiment will not be described in detail here.

[0175] Obviously, those skilled in the art should understand that the above modules or steps of the present application can be implemented with a general computing system, they can be concentrated on a single computing system, or distributed on a network composed of multiple computing systems, and optionally, they can be implemented with program codes executable by the computing system, so that they can be stored in a storage system and run by the computing system, and in some cases, the steps shown or described can be run in a different order than here, or they can be made into individual integrated circuit modules, or multiple modules or steps therein can be made into a single integrated circuit module for implementation. Thus, the present application is not limited to any specific combination of hardware and software.

[0176] The above description is only the preferred embodiment of the present application and is not intended to limit the present application. For those skilled in the art, the present application may have various modifications and variations. Any modification, equivalent replacement, improvement, etc. made within the principles of the present application shall be included in the protection scope of the present application.

Claims

1. A method for determining monitoring results, characterized in that: include: In case a monitoring module is deployed in the middleware of the vehicle, sending configuration rules to other modules in the middleware; Receiving the reported data fed back by the other modules based on the configuration rules; The monitoring result of the middleware is determined through the reported data.

2. The method for determining monitoring results according to claim 1, characterized in that: Sending configuration rules to other modules in the middleware includes: Determine a node attribute of the monitoring module in a preset cluster, wherein the preset cluster includes a plurality of monitoring modules corresponding to a plurality of different domains of the vehicle, the plurality of monitoring modules include the monitoring module, and the plurality of different domains correspond one-to-one to the plurality of monitoring modules; When the node attribute is the first attribute, sending the first rule deployed in the monitoring module as the configuration rule to the other modules; In the case where the node attribute is a second attribute, the second rule received by the monitoring module from the target monitoring module having the first attribute is sent to the other modules, wherein the multiple monitoring modules include: the target monitoring module.

3. The method for determining monitoring results according to claim 2, characterized in that: Before sending the configuration rules to other modules in the middleware, the method further includes: Receive a configuration file written in a preset configuration mode; In a case where the configuration file records a first configuration, determining that the node attribute of the monitoring node is the first attribute; When the second configuration is recorded in the configuration file, the node attribute of the monitoring node is determined to be the second attribute.

4. The method for determining monitoring results according to claim 2, characterized in that: Determining the monitoring result of the middleware through the reported data includes: When the node attribute of the monitoring module is the second attribute, performing a first processing operation on the reported data to obtain first summary data; The first summary data is sent to the target monitoring module, and a monitoring result of the middleware is determined according to the first summary data.

5. The method for determining monitoring results according to claim 2, characterized in that: Determining the monitoring result of the middleware through the reported data includes: When the node attribute of the monitoring module is the first attribute, performing a first processing operation on the reported data to obtain second summary data; and Receiving first summary data reported by other monitoring modules among the plurality of monitoring modules except the target monitoring module; Performing a second processing operation on the first summary data and the second summary data to obtain third summary data; The monitoring results of the middlewares respectively corresponding to the multiple different domains are determined by the third summary data.

6. The method for determining monitoring results according to claim 1, characterized in that: Sending configuration rules to other modules in the middleware includes: When the monitoring module is started, sending the configuration rules to the other modules; When the monitoring module has been started and the other modules have not received the configuration rules, the configuration rules are issued to the other modules according to the configuration request sent by the other modules.

7. The method for determining monitoring results according to claim 1, characterized in that: Receiving the reported data fed back by the other modules based on the configuration rule, including: Determining the number of data groups of the reported data received within a current time interval; In the case where the number of data groups meets the number of modules of the other modules, determining that the reported data required to be received within the current time has been received; When the number of data groups does not satisfy the number of modules of other modules, a first alarm event is executed.

8. A device for determining monitoring results, characterized in that: include: A sending module, used to send configuration rules to other modules in the middleware when a monitoring module is deployed in the middleware of the vehicle; A receiving module, used for receiving the reported data fed back by the other modules based on the configuration rules; A determination module is used to determine the monitoring result of the middleware through the reported data.

9. A computer-readable storage medium, characterized in that: The computer-readable storage medium includes a stored program, wherein the program executes the method described in any one of claims 1 to 7 when executed.

10. An electronic device comprising a memory and a processor, characterized in that: A computer program is stored in the memory, and the processor is configured to execute the method according to any one of claims 1 to 7 through the computer program.

Images