Vehicle-mounted software monitoring method, device and equipment and storage medium

Abstract

The invention provides a vehicle-mounted software monitoring method and device, equipment and a storage medium. The method comprises the steps of obtaining monitoring data of vehicle-mounted software in a running state and a current monitoring mode for the vehicle-mounted software; determining a target monitoring mode based on the attribute category of the monitoring data and a preset corresponding relationship between the attribute category of the monitoring data and the monitoring mode; and switching the current monitoring mode into the target monitoring mode to monitor the resource information of the vehicle-mounted software based on the target monitoring mode. Thus, through the attribute category of the monitoring data of the vehicle-mounted software and the preset corresponding relation between the attribute category of the monitoring data and the monitoring mode, the target monitoring mode more adaptive to the vehicle-mounted software can be determined, and furthermore, the current monitoring mode is switched into the target monitoring mode, so that the monitoring efficiency is improved. Reasonable distribution of system resources of the monitoring system software can be realized, so that detailed information of abnormity or fault occurrence of the vehicle-mounted software can be accurately positioned, and the fault diagnosis accuracy of the vehicle-mounted software is improved.

Description

Technical Field

[0001] The present application relates to the field of vehicle-mounted software technology, and specifically to a vehicle-mounted software monitoring method, device, equipment and storage medium. Background Art

[0002] As cars become increasingly intelligent and electronic, consumers are no longer satisfied with basic driving needs, but are pursuing a more diverse intelligent experience. Therefore, a stable, reliable, flexible and intelligent vehicle software platform has become one of the directions for companies to compete and develop. Effective hardware resources carrying a large number of intelligent software function modules is undoubtedly a challenge to the platform system. During the product development process, a large number of system freezes caused by system resources will inevitably occur, leading to functional abnormalities and other problems. Based on the particularity of the product, the diversity of test conditions, and the uncertainty of problem reproduction, the development cycle and problem convergence efficiency have been greatly increased. Therefore, it is particularly important to form a complete set of system resource monitoring methods.

[0003] In the related art, a monitoring system is usually used to monitor the system resources of the vehicle-mounted software. However, the monitoring system itself will also occupy system resources. Unreasonable resource allocation will not be able to accurately locate the detailed information of the abnormality or failure of the process module of the vehicle-mounted software, thereby reducing the accuracy of fault diagnosis of the vehicle-mounted software. Summary of the invention

[0004] The present application provides a vehicle-mounted software monitoring method, device, equipment and storage medium, which can achieve reasonable allocation of system resources, thereby locating the abnormality and fault information of the vehicle-mounted software with greater accuracy, and improving the accuracy of fault diagnosis of the vehicle-mounted software.

[0005] The technical solution of this application is implemented as follows:

[0006] An embodiment of the present application provides a method for monitoring vehicle-mounted software, including: obtaining monitoring data of vehicle-mounted software in a running state and a current monitoring mode for the vehicle-mounted software; determining a target monitoring mode corresponding to the monitoring data based on attribute categories of the monitoring data and a preset correspondence between the attribute categories of the monitoring data and the monitoring mode; if the current monitoring mode and the target monitoring mode are different, switching the current monitoring mode to the target monitoring mode to monitor resource information of the vehicle-mounted software based on the target monitoring mode.

[0007] According to the above-mentioned technical means, through the attribute categories of the monitoring data of the vehicle-mounted software, and the preset correspondence between the attribute categories of the monitoring data and the monitoring mode, a target monitoring mode that is more suitable for the vehicle-mounted software can be determined. Furthermore, by switching the current monitoring mode to the target monitoring mode, the reasonable allocation of system resources of the monitoring system software can be achieved, so that the detailed information of the abnormality or failure of the vehicle-mounted software can be accurately located, thereby improving the fault diagnosis accuracy of the vehicle-mounted software.

[0008] Furthermore, the monitoring data includes multiple monitoring data corresponding to multiple attribute categories; based on the attribute categories of the monitoring data, and the preset correspondence between the attribute categories of the monitoring data and the monitoring modes, determining the target monitoring mode corresponding to the monitoring data, including: determining the first monitoring mode corresponding to each type of monitoring data based on the attribute categories corresponding to each of the multiple monitoring data, and the preset correspondence between the attribute categories of the monitoring data and the monitoring modes; determining the target monitoring mode from each first monitoring mode based on the type of vehicle-mounted software corresponding to each of the multiple monitoring data, and the preset priority order of each type of vehicle-mounted software monitoring data.

[0009] According to the above-mentioned technical means, the first monitoring mode corresponding to each type of monitoring data is determined by the preset correspondence between the monitoring data attribute category and the monitoring mode, and based on the type of vehicle-mounted software corresponding to the monitoring data and the preset priority order of the vehicle-mounted software monitoring data, the target monitoring mode adapted to the corresponding priority of the monitoring data of the vehicle-mounted software can be determined, thereby ensuring the stability and rationality of the monitoring function.

[0010] Further, the method also includes: the monitoring mode includes a configuration module monitoring mode, a specific process module monitoring mode, a configuration information self-recovery monitoring mode and a process module full monitoring mode; based on the attribute categories corresponding to each of the multiple monitoring data, and the preset correspondence between the monitoring data attribute categories and the monitoring modes, determine the first monitoring mode corresponding to each type of monitoring data; including: if the reference monitoring data is a first attribute category, based on the preset correspondence, determine that the first monitoring mode corresponding to the reference monitoring data is a configuration module monitoring mode; the reference monitoring data is any one of the multiple monitoring data; if the reference monitoring data is a second attribute category, based on the preset correspondence, determine that the first monitoring mode corresponding to the reference monitoring data is a specific process module monitoring mode; if the reference monitoring data is a third attribute category, based on the preset correspondence, determine that the first monitoring mode corresponding to the reference monitoring data is a configuration information self-recovery monitoring mode; if the reference monitoring data is a fourth attribute category, based on the preset correspondence, determine that the first monitoring mode corresponding to the reference monitoring data is a process module full monitoring mode.

[0011] According to the above-mentioned technical means, when the reference monitoring data corresponds to different attribute categories, the first monitoring mode corresponding to the reference monitoring data is determined as the configuration module monitoring mode, the specific process module monitoring mode, the configuration information self-recovery monitoring mode and the process module full monitoring mode, so as to determine a more reasonable first monitoring mode according to the attributes of the monitoring data, so as to facilitate the subsequent accurate positioning of the problems of the vehicle-mounted software according to the first monitoring mode.

[0012] Furthermore, based on the types of vehicle-mounted software corresponding to each of the multiple monitoring data and the preset priority order of the monitoring data of each type of vehicle-mounted software, a target monitoring mode is determined from each first monitoring mode, including: sorting the first monitoring modes of the monitoring data corresponding to each type of vehicle-mounted software according to the types of vehicle-mounted software corresponding to each of the multiple monitoring data and the preset priority order to obtain a monitoring mode sorting result; the vehicle-mounted software types include vehicle-mounted operating systems, vehicle-mounted application software and monitoring systems; and determining the target monitoring mode based on the monitoring mode sorting result.

[0013] According to the above-mentioned technical means, by sorting the first monitoring modes of the monitoring data corresponding to each type of vehicle-mounted software according to the vehicle-mounted software types and preset priority orders corresponding to multiple monitoring data, and determining the target monitoring mode based on the obtained monitoring mode sorting results, the target monitoring mode finally obtained can be matched with the priority of the vehicle-mounted software monitoring data, so that in the subsequent process of monitoring the vehicle-mounted software based on the target monitoring mode, the fault point of the vehicle-mounted software can be located more accurately.

[0014] Furthermore, the process of creating a preset correspondence between monitoring data attribute categories and monitoring modes includes: obtaining multiple monitoring data samples; determining the reference attribute categories corresponding to each monitoring data sample, and the reference monitoring scenes corresponding to each monitoring data sample; the reference monitoring scenes corresponding to monitoring data samples of the same reference attribute category are the same; and creating a preset correspondence between monitoring data attribute categories and monitoring modes based on the preset correspondence between each reference attribute category and each reference monitoring scene, as well as the monitoring scene and the monitoring mode.

[0015] According to the above-mentioned technical means, by determining the reference attribute categories and reference control scenarios corresponding to the monitoring data samples, and based on the correspondence between the reference attribute categories and the reference monitoring scenarios, and the preset correspondence between the monitoring scenarios and the monitoring modes, the mapping relationship between the monitoring data attribute categories and the monitoring modes is obtained, so that in the subsequent process of monitoring the vehicle-mounted software, the target monitoring mode can be quickly determined according to the mapping relationship.

[0016] Furthermore, the monitoring data of the vehicle-mounted software in operation is obtained, including: obtaining an information table of each process module of the vehicle-mounted software; the information table includes identification information of each process module; based on the monitoring configuration information and the identification information, each process module is divided into a first process module and a second process module; the first process module does not include the process module of the vehicle-mounted system, and the second process module includes the process module of the vehicle-mounted system; based on the first monitoring strategy, the first monitoring data of the first process module is obtained, and based on the second monitoring strategy, the second monitoring data of the second process module is obtained; the first monitoring strategy includes monitoring of resource information of threads corresponding to the process modules, and the second monitoring strategy does not include monitoring of resource information of threads corresponding to the process modules; based on the first monitoring data and the second monitoring data, the monitoring data of the vehicle-mounted software is obtained.

[0017] According to the above-mentioned technical means, by dividing the various process modules of the vehicle-mounted software into a first process module and a second process module, and assigning different monitoring strategies to the first process module and the second process module for monitoring, comprehensive monitoring of the vehicle-mounted software can be achieved, and the monitoring of the first process module of concern can be further refined. At the same time, the resource usage of the second process module that is not often concerned is also taken into account, so that resource abnormality failures can be located more comprehensively, thereby improving the monitoring capabilities of the vehicle-mounted software.

[0018] Further, based on the first monitoring strategy, the first monitoring data of the first process module is obtained, including: obtaining the first resource overhead data corresponding to the first process module; if the first resource overhead data is greater than the first resource overhead threshold, obtaining the second resource overhead data of the thread corresponding to the first process module; if the second resource overhead data is greater than the second resource overhead threshold, determining the first resource overhead data and the second overhead data as the first monitoring data.

[0019] According to the above-mentioned technical means, when the first resource overhead data of the first process module is greater than the first resource overhead threshold, the second resource overhead data of the thread corresponding to the first process module is further obtained, so that more detailed monitoring information of the first process module can be obtained, thereby improving the monitoring granularity of the first process module.

[0020] Further, second monitoring data of the second process module is obtained based on the second monitoring strategy, including: obtaining third resource overhead data corresponding to the second process module; if the third resource overhead data is greater than the first resource overhead threshold, determining the third resource overhead data as the second monitoring data.

[0021] According to the above-mentioned technical means, when it is determined that the third resource overhead data of the second process module is greater than the first resource overhead threshold corresponding to the process, the third resource overhead data at the process level is directly determined as the second monitoring data, so as to obtain the resource information occupancy status of the second process module that is not often paid attention to (such as the process module of the vehicle system), so as to further locate the anomalies and faults of the vehicle software more accurately based on the second monitoring data of the second process module.

[0022] The embodiment of the present application provides a vehicle-mounted software monitoring device, characterized in that it includes:

[0023] A first acquisition module is used to acquire monitoring data of the vehicle-mounted software in operation and a current monitoring mode for the vehicle-mounted software;

[0024] A first determination module, configured to determine a target monitoring mode corresponding to the monitoring data based on an attribute category of the monitoring data and a preset correspondence between the attribute category of the monitoring data and the monitoring mode;

[0025] The first switching module is used to switch the current monitoring mode of the vehicle-mounted software to the target monitoring mode if the current monitoring mode and the target monitoring mode are different, so as to monitor the resource information of the vehicle-mounted software based on the target monitoring mode.

[0026] The embodiment of the present application provides a vehicle-mounted software monitoring device, including:

[0027] A memory for storing computer programs that can be run on the processor;

[0028] The processor is used to execute the vehicle software monitoring method provided in the embodiment of the present application when running a computer program.

[0029] An embodiment of the present application provides a computer-readable storage medium, in which computer-executable instructions are stored, and the computer-executable instructions are configured to execute the above-mentioned vehicle-mounted software monitoring method. BRIEF DESCRIPTION OF THE DRAWINGS

[0030] Figure 1 A flowchart of a vehicle software monitoring method provided in an embodiment of the present application;

[0031] Figure 2 A schematic diagram of the structure of a monitoring system based on an intelligent driving vehicle controller software platform provided in an embodiment of the present application;

[0032] Figure 3 A flowchart of a method for fully monitoring thread resources provided in an embodiment of the present application;

[0033] Figure 4 A schematic diagram of a flow chart of a first threshold strategy provided in an embodiment of the present application;

[0034] Figure 5 A schematic diagram of a flow chart of a second threshold strategy provided in an embodiment of the present application;

[0035] Figure 6 A schematic diagram of a flow chart of a third threshold strategy provided in an embodiment of the present application;

[0036] Figure 7 A schematic diagram of a flow chart of a method for adaptively switching monitoring modes based on a scenario provided in an embodiment of the present application;

[0037] Figure 8 A schematic diagram of a matching rule between a monitoring signal and a scene provided in an embodiment of the present application;

[0038] Fig. 9 A schematic diagram of the relationship between a monitoring mode and a policy configuration provided in an embodiment of the present application;

[0039] Fig.10 A schematic diagram of the structure of a vehicle-mounted software monitoring device provided in an embodiment of the present application;

[0040] Fig.11 A schematic diagram of the composition structure of a vehicle-mounted software monitoring device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0041] The technical solutions 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.

[0042] In order to make the purpose, technical solutions and advantages of the present application clearer, the present application will be further described below in conjunction with the accompanying drawings. The described embodiments should not be regarded as limiting the present application. All other embodiments obtained by other ordinary technicians in the field without making creative work are within the scope of protection of the present application.

[0043] In the following description, reference is made to “some embodiments\other embodiments”, which describe a subset of all possible embodiments, but it can be understood that “some embodiments\other embodiments” may be the same subset or different subsets of all possible embodiments and may be combined with each other without conflict.

[0044] In the following description, the terms "first\second\third" involved are merely used to distinguish similar objects and do not represent a specific ordering of the objects. It can be understood that "first\second\third" can be interchanged with a specific order or sequence where permitted, so that the embodiments of the present application described herein can be implemented in an order other than that illustrated or described herein.

[0045] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as those commonly understood by other technicians in the technical field of this application. The terms used herein are only for the purpose of describing the embodiments of this application and are not intended to limit this application.

[0046] In the related art, a multi-application processing method for a vehicle-mounted system-on-chip (SoC) proposes a method for health management and system resource monitoring of designated software through an executable management daemon (middleware-like); on this basis, a vehicle data collection method dynamically adjusts the execution or suspension of collection tasks by adopting a resource allocation server and a data collection server. These two methods have the following problems: First, the monitoring scope is limited, and most of them are basic system resource monitoring around a certain application module or chip-level underlying software, and cannot monitor the resource information of process modules other than the specified one (such as the process module of the vehicle-mounted system); second, the monitoring cycle is too long, and it is impossible to monitor the system resource usage allocation during sudden failures; third, the fault diagnosis capability is limited, and it is impossible to implement thread-level precise positioning for resource allocation anomalies of a certain module or application.

[0047] Based on the problems existing in the related art, the embodiment of the present application provides a vehicle-mounted software monitoring method, which can realize the reasonable allocation of system resources, thereby locating the abnormality and fault information of the vehicle-mounted software with greater accuracy, and improving the fault diagnosis accuracy of the vehicle-mounted software. Figure 1 FIG. 1 is a flow chart of a vehicle software monitoring method provided by an embodiment of the present application, and the method comprises the following steps:

[0048] S101, obtaining monitoring data of the vehicle-mounted software in operation and the current monitoring mode of the vehicle-mounted software.

[0049] If necessary, the vehicle-mounted software may be application software, vehicle-mounted system software, or monitoring system software installed in the vehicle-mounted device, wherein the monitoring system software may be functional software for monitoring the system resources of the application software, vehicle-mounted system software, and the monitoring system software itself.

[0050] In some embodiments, the monitoring data may include system resource information occupied by the vehicle-mounted software during operation, such as central processing unit (CPU) overhead, memory overhead, number of threads, most recently run core, priority, process input / output (IO), etc. When the vehicle-mounted software is turned on or in running state, the monitoring data of the vehicle-mounted software can be obtained through the monitoring system software in the vehicle-mounted device.

[0051] In some embodiments, the current monitoring mode of the vehicle-mounted software may be the monitoring mode adopted by the monitoring software system for the vehicle-mounted software, and the current monitoring mode may include a general monitoring mode and a special monitoring mode. The general monitoring mode may be the monitoring mode set by default for the monitoring system software, for example, the vehicle-mounted software is monitored by using the default monitoring data collection frequency and opening a preset number of functional modules; the special monitoring mode may include a configuration module monitoring mode, a specific process monitoring mode, a configuration information self-recovery monitoring mode, and a process module full monitoring mode, etc. In the configuration module monitoring mode, only the configuration module of the monitoring system software may be running, and other functional modules of the monitoring software are suspended; in the specific process monitoring mode, only the system resource information of the process module of the vehicle-mounted software recorded by the configuration information of the monitoring system software may be recorded, wherein the specific process may be recorded in the configuration information of the monitoring system software; in the configuration information self-recovery mode, the monitoring system software may be monitored based on the configuration information saved at the last time after startup; in the process module full monitoring mode, all functional modules or process modules of the monitoring system software may be running.

[0052] In some embodiments, the current monitoring mode corresponding to the vehicle-mounted software can be determined based on the current operating status of each functional module of the monitoring system software and the objects monitored by the monitoring system software, where the operating status can be whether the functional module is turned on or off, and the objects monitored by the monitoring system software can include various process modules of the vehicle-mounted software.

[0053] S102: Determine a target monitoring mode corresponding to the monitoring data based on the attribute category of the monitoring data and the preset correspondence between the attribute category of the monitoring data and the monitoring mode.

[0054] In some embodiments, the attribute category of the monitoring data may be the data type to which the monitoring data belongs, and the data type may include system resource overrun, debugging signal issued by a process module, forced exit, and CPU overhead overrun of a specific process module, etc. The preset correspondence between the attribute category of the monitoring data and the monitoring mode may be pre-created, and different types of monitoring data may correspond to different monitoring modes.

[0055] In some embodiments, the target monitoring mode and the current monitoring mode of the vehicle-mounted software may be the same or different. The current monitoring mode is the actual monitoring mode adopted by the monitoring system software for the vehicle-mounted software, and the target monitoring mode may be a theoretical monitoring mode. After determining the attribute category of the monitoring data, the attribute category of the monitoring data can be matched with the attribute category of the monitoring data in the preset correspondence table to determine the target monitoring mode.

[0056] S103: If the current monitoring mode and the target monitoring mode are different, the current monitoring mode of the vehicle-mounted software is switched to the target monitoring mode, so as to monitor the resource information of the vehicle-mounted software based on the target monitoring mode.

[0057] In some embodiments, when it is determined that the current monitoring mode and the target monitoring mode are different, the purpose of switching the current monitoring mode to the target monitoring mode can be achieved by controlling the working status of each functional module of the monitoring system software, the number of process modules of the monitored vehicle software, etc.

[0058] Exemplarily, if the current monitoring mode is the general monitoring mode and the target monitoring mode is the full monitoring mode of the process module, all functional modules of the monitoring system software can be run, thereby realizing the switch from the general monitoring mode to the full monitoring mode of the process module; if the current monitoring mode is the full monitoring mode of the process module and the target monitoring mode is the specific process monitoring mode, some functional modules of the monitoring system software can be turned off, and the monitoring of some monitored process modules can be stopped, and only the specified process modules can be monitored, thereby realizing the switch from the full monitoring mode of the process module to the specific process monitoring mode. The current monitoring mode, the target monitoring mode, and the way of converting the current monitoring mode to the target monitoring mode are merely exemplary descriptions, and this application does not limit this.

[0059] In some embodiments, after the monitoring mode corresponding to the vehicle-mounted software is switched to the target monitoring mode, the target monitoring mode can be used to continue to monitor the resource information of the vehicle-mounted software. The resource information may be the system resources occupied during the operation of the vehicle-mounted software, such as CPU overhead, memory overhead, etc.

[0060] In an embodiment of the present application, the monitoring data of the vehicle-mounted software in operation and the current monitoring mode for the vehicle-mounted software are obtained; based on the attribute categories of the monitoring data and the preset correspondence between the attribute categories of the monitoring data and the monitoring mode, the target monitoring mode corresponding to the monitoring data is determined; if the current monitoring mode and the target monitoring mode are different, the current monitoring mode is switched to the target monitoring mode to monitor the resource information of the vehicle-mounted software based on the target monitoring mode. In this way, through the attribute categories of the monitoring data of the vehicle-mounted software and the preset correspondence between the attribute categories of the monitoring data and the monitoring mode, a target monitoring mode that is more suitable for the vehicle-mounted software can be determined. Further, by switching the current monitoring mode to the target monitoring mode, the reasonable allocation of system resources of the monitoring system software can be achieved, so that the detailed information of the abnormality or failure of the vehicle-mounted software can be accurately located, and the fault diagnosis accuracy of the vehicle-mounted software can be improved.

[0061] In some embodiments of the present application, in the process of obtaining monitoring data of vehicle-mounted software in a running state, an information table of each process module of the vehicle-mounted software can be obtained; based on the monitoring configuration information and identification information, each process module is divided into a first process module and a second process module; based on the first monitoring strategy, the first monitoring data of the first process module is obtained, and based on the second monitoring strategy, the second monitoring data of the second process module is obtained; based on the first monitoring data and the second monitoring data, the monitoring data of the vehicle-mounted software is obtained.

[0062] In some embodiments, the information table includes identification information of each process module of the vehicle-mounted software. The identification information may include a process identifier (PID). The identification information may also include the name of the process module. The PID and the name of the process module correspond one to one. The information table of each process module may be created when the vehicle-mounted software starts running, so it can be directly obtained when the vehicle-mounted software needs to be monitored.

[0063] In some embodiments, the first process module does not include the process module of the vehicle-mounted system, and may include the process module of the vehicle-mounted application software and the process module of the monitoring system software; the second process module includes the process module of the vehicle-mounted system, and the second process module may include one or more process modules of the vehicle-mounted system software.

[0064] In some embodiments, the monitoring configuration information may include reference identification information of a preset reference process module, and the reference identification information may include information such as the PID and name of the reference process module, and the reference process module may include at least one process module of the vehicle-mounted system software, the vehicle-mounted application software, and the vehicle-mounted system software. The reference identification information in the monitoring configuration information may be compared with the identification information in the information table, and the process module corresponding to the identification information in the information table that is the same as the reference identification information is determined as the first process module, and the process module corresponding to the identification information in the information table that is different from the reference identification information is determined as the second process module.

[0065] In some embodiments, the first monitoring strategy includes monitoring the resource information of the thread corresponding to the process module, and the second monitoring strategy does not include monitoring the resource information of the thread corresponding to the process module, that is, the first monitoring strategy can only monitor the resource information of the first process module, and the second monitoring strategy can monitor the second process module and the resource information of the thread corresponding to the second process module.

[0066] In some embodiments, since the first monitoring strategy and the second monitoring strategy are different, the first monitoring data obtained by monitoring the first process module based on the first monitoring strategy may be different from the second monitoring data obtained by monitoring the second process module based on the second monitoring strategy.

[0067] In some embodiments, the first monitoring data may include the occupation information of the first process module on system resources, the occupation information of the thread corresponding to the first process module on system resources, the identification information of the process to which the thread belongs, the identification information of the first process module, etc. The second monitoring data may include the occupation information of the second process module on system resources, the identification information corresponding to the second process module, etc. The first monitoring data and the second monitoring data may be integrated to obtain the monitoring data of the vehicle-mounted software.

[0068] According to the above-mentioned technical means, by dividing the various process modules of the vehicle-mounted software into a first process module and a second process module, and assigning different monitoring strategies to the first process module and the second process module for monitoring, comprehensive monitoring of the vehicle-mounted software can be achieved, and the monitoring of the first process module of concern can be further refined. At the same time, the resource usage of the second process module that is not often concerned is also taken into account, so that resource abnormality failures can be located more comprehensively, thereby improving the monitoring capabilities of the vehicle-mounted software.

[0069] In some embodiments of the present application, in the process of obtaining the first monitoring data of the first process module based on the first monitoring strategy, the first resource overhead data corresponding to the first process module can be obtained; if the first resource overhead data is greater than the first resource overhead threshold, the second resource overhead data of the thread corresponding to the first process module is obtained; if the second resource overhead data is greater than the second resource overhead threshold, the first resource overhead data and the second overhead data are determined as the first monitoring data.

[0070] In some embodiments, the first resource overhead data may include information such as CPU overhead, memory overhead, number of threads, most recently run core, priority, process IO, and process scheduling of the first process module.

[0071] In some embodiments, the first resource cost threshold may include the CPU cost and memory cost threshold corresponding to the process, etc., and the first resource cost may be set by the configuration module of the monitoring system software. The second resource cost data may include the CPU cost, memory cost, priority and other information of the thread corresponding to the second process module.

[0072] In some embodiments, when it is determined that the CPU overhead of the first process module is greater than the process CPU overhead threshold, the second resource overhead data of the thread corresponding to the first process module can be further obtained; or, when it is determined that the memory overhead of the first process module is greater than the memory overhead threshold corresponding to the process, the second resource overhead data of the thread corresponding to the first process module can be further obtained; or, when it is determined that the CPU overhead of the first process module is greater than the process CPU overhead threshold, and the memory overhead of the first process module is greater than the memory overhead threshold corresponding to the process, the second resource overhead data of the thread corresponding to the first process module can be further obtained.

[0073] In some embodiments, the second resource overhead threshold may include a CPU overhead threshold and a memory overhead threshold corresponding to the thread, etc. The second resource overhead data may be different from the first resource overhead data, and the first resource overhead threshold may be greater than the second resource overhead threshold.

[0074] In some embodiments, when it is determined that the CPU overhead of the thread corresponding to the first process module is greater than the thread CPU overhead threshold, the first resource overhead data and the second overhead data can be determined as the first monitoring data; or, when it is determined that the memory overhead of the thread corresponding to the first process module is greater than the memory overhead threshold corresponding to the thread, the first resource overhead data and the second overhead data can be determined as the first monitoring data; or, when it is determined that the CPU overhead of the thread corresponding to the first process module is greater than the thread CPU overhead threshold, and the memory overhead of the thread corresponding to the first process module is greater than the memory overhead threshold corresponding to the thread, the first resource overhead data and the second overhead data can be determined as the first monitoring data.

[0075] In some embodiments, the second resource overhead data may be marked in the obtained first monitoring data to indicate that the first process module includes resource overhead data of the corresponding thread.

[0076] According to the above-mentioned technical means, when the first resource overhead data of the first process module is greater than the first resource overhead threshold, the second resource overhead data of the thread corresponding to the first process module is further obtained, so that more detailed monitoring information of the first process module can be obtained, thereby improving the monitoring granularity of the first process module.

[0077] In some embodiments of the present application, in the process of obtaining second monitoring data of the second process module based on the second monitoring strategy, third resource overhead data corresponding to the second process module can be obtained; if the third resource overhead data is greater than the first resource overhead threshold, the third resource overhead data is determined as the second monitoring data.

[0078] In some embodiments, the third resource overhead data may include information such as the CPU overhead, memory overhead, number of threads, most recently run core, priority, process IO and process scheduling of the second process module.

[0079] In some embodiments, when it is determined that the CPU overhead of the second process module is greater than the process CPU overhead threshold, the third resource overhead data can be determined as the second monitoring data; or, when it is determined that the memory overhead of the second process module is greater than the memory overhead threshold corresponding to the process, the third resource overhead data can be determined as the second monitoring data; or, when it is determined that the CPU overhead of the second process module is greater than the process CPU overhead threshold, and the memory overhead of the second process module is greater than the memory overhead threshold corresponding to the process, the third resource overhead data can be determined as the second monitoring data.

[0080] According to the above-mentioned technical means, when it is determined that the third resource overhead data of the second process module is greater than the first resource overhead threshold corresponding to the process, the third resource overhead data at the process level is directly determined as the second monitoring data, so as to obtain the resource information occupancy status of the second process module that is not often paid attention to (such as the process module of the vehicle system), so as to further locate the anomalies and faults of the vehicle software more accurately based on the second monitoring data of the second process module.

[0081] In some embodiments of the present application, the monitoring data includes multiple monitoring data corresponding to multiple types. Based on this, based on the attribute category of the monitoring data, and the preset correspondence between the attribute category of the monitoring data and the monitoring mode, the target monitoring mode corresponding to the monitoring data is determined, that is, the above-mentioned step S102 can be implemented by the following steps S1021 to S1022, and each step is explained separately below.

[0082] S1021. Determine a first monitoring mode corresponding to each type of monitoring data based on the attribute categories corresponding to each of the plurality of monitoring data and the preset correspondence between the attribute categories of the monitoring data and the monitoring mode.

[0083] In some embodiments, different monitoring data may correspond to different types. Each monitoring data may be traversed in turn to determine the attribute category of each monitoring data, and the monitoring data of the same type may be grouped together to obtain multiple category groups. Then, the preset correspondence between the monitoring data attribute category and the monitoring mode may be combined to determine the first monitoring data corresponding to each monitoring data in the different category groups.

[0084] In some embodiments, the preset correspondence between the monitoring data attribute category and the monitoring mode can be pre-created, and the preset correspondence can be represented by a correspondence table between the monitoring data attribute category and the monitoring mode, and the correspondence table can record information such as each monitoring data attribute category and the name of the corresponding monitoring module. The category information of each category group of monitoring data can be matched with the monitoring data attribute category in the preset correspondence table, so as to determine the first monitoring mode corresponding to each of the monitoring data in each category group.

[0085] S1022. Determine a target monitoring mode from each first monitoring mode based on the types of vehicle-mounted software corresponding to each of the plurality of monitoring data and a preset priority order of each type of vehicle-mounted software monitoring data.

[0086] In some embodiments, the vehicle-mounted software type corresponding to each of the multiple monitoring data may be the source information of the monitoring data, that is, which type of vehicle-mounted software the monitoring data belongs to. The vehicle-mounted software types include vehicle-mounted system software, vehicle-mounted application software and monitoring system software. The preset priority order of each type of vehicle-mounted software monitoring data may be predetermined.

[0087] In some embodiments, after determining the vehicle software type corresponding to the monitoring data, the monitoring data corresponding to different vehicle software types can be sorted based on a preset priority order of the vehicle software monitoring data, and then the target monitoring mode can be determined according to the sorting result.

[0088] According to the above-mentioned technical means, the first monitoring mode corresponding to each type of monitoring data is determined by the preset correspondence between the monitoring data attribute category and the monitoring mode, and based on the type of vehicle-mounted software corresponding to the monitoring data and the preset priority order of the vehicle-mounted software monitoring data, the target monitoring mode adapted to the corresponding priority of the monitoring data of the vehicle-mounted software can be determined, thereby ensuring the stability and rationality of the monitoring function.

[0089] In some embodiments of the present application, the monitoring mode includes a configuration module monitoring mode, a specific process module monitoring mode, a configuration information self-recovery monitoring mode and a full process module monitoring mode. Based on this, based on the attribute categories corresponding to each of the multiple monitoring data, and the preset correspondence between the monitoring data attribute categories and the monitoring modes, the implementation method of determining the first monitoring mode corresponding to each type of monitoring data may include: if the reference monitoring data is the first attribute category, based on the preset correspondence, determining that the first monitoring mode corresponding to the reference monitoring data is the configuration module monitoring mode;.

[0090] In some embodiments, the reference monitoring data is any one of a plurality of monitoring data. The preset correspondence may include a one-to-one correspondence between monitoring data attribute categories and monitoring modes. The monitoring data attribute categories may include system resource overruns, debugging signals issued by process modules, forced exits, and CPU overhead overruns of specific process modules, etc. The first attribute category may be system resource overruns, that is, according to the preset correspondence, when it is determined that the reference monitoring data is a signal of the system resource overrun type, the configuration module monitoring mode may be determined as the first monitoring mode corresponding to the reference monitoring data. When monitoring data of system resource overruns is obtained, the configuration module monitoring mode is determined as the first monitoring mode, and in the configuration module monitoring mode, only the configuration module of the monitoring system software may be run, and other modules may be suspended, thereby reducing the resource usage of the monitoring system software.

[0091] In some embodiments, based on the attribute categories corresponding to each of the multiple monitoring data and the preset correspondence between the attribute categories of the monitoring data and the monitoring modes, the implementation method of determining the first monitoring mode corresponding to each type of monitoring data may include: if the reference monitoring data is of the second attribute category, based on the preset correspondence, determining that the first monitoring mode corresponding to the reference monitoring data is a specific process module monitoring mode.

[0092] In some embodiments, the second attribute category may be a debugging signal issued by a process module, that is, according to a preset corresponding relationship, when the reference monitoring data is determined to be a debugging signal issued by a process module, the specific process module monitoring mode may be determined as the first monitoring mode corresponding to the reference monitoring data. When the reference monitoring data obtained is a debugging signal issued by a process module, the specific process module monitoring mode is determined as the first monitoring mode, thereby enabling comprehensive monitoring of the process module that issues the debugging signal, so as to focus more on the anomalies of the specific process module.

[0093] In some embodiments, based on the attribute categories corresponding to each of the multiple monitoring data and the preset correspondence between the attribute categories of the monitoring data and the monitoring modes, the implementation method of determining the first monitoring mode corresponding to each type of monitoring data may include: if the reference monitoring data is a third attribute category, based on the preset correspondence, determining that the first monitoring mode corresponding to the reference monitoring data is a configuration information self-recovery monitoring mode.

[0094] In some embodiments, the third attribute category may be forced exit, that is, according to a preset corresponding relationship, when the reference monitoring data is determined to be a forced exit signal, the configuration information self-recovery mode may be determined as the first monitoring mode corresponding to the reference monitoring data. When the reference monitoring data obtained is a forced exit signal, the self-recovery monitoring mode is determined as the first monitoring mode, and after the system is started, monitoring may be performed directly based on the configuration information saved when the monitoring system software was last shut down, thereby increasing the startup speed of the monitoring function.

[0095] In some embodiments, based on the attribute categories corresponding to each of the multiple monitoring data and the preset correspondence between the attribute categories of the monitoring data and the monitoring modes, the implementation method of determining the first monitoring mode corresponding to each type of monitoring data may include: if the reference monitoring data is the fourth attribute category, based on the preset correspondence, determining that the first monitoring mode corresponding to the reference monitoring data is the full monitoring mode of the process module.

[0096] In some embodiments, the fourth attribute category may be that the CPU overhead of a specific process module exceeds the limit, that is, according to the preset corresponding relationship, when it is determined that the reference monitoring data is that the CPU overhead of a specific process module exceeds the limit, the full monitoring mode of the process module can be determined as the first monitoring mode corresponding to the reference monitoring data. When the reference monitoring data obtained is that the CPU overhead of a specific process module exceeds the limit, the full monitoring mode of the process module is determined as the first monitoring mode corresponding to the reference process module, and in the full monitoring mode of the process module, all functional modules of the monitoring system software are turned on, which can avoid the problem of abnormalities or fault location errors of other vehicle-mounted software caused by the failure to turn on some functional modules of the monitoring system software.

[0097] According to the above-mentioned technical means, when the reference monitoring data corresponds to different attribute categories, the first monitoring mode corresponding to the reference monitoring data is determined as the configuration module monitoring mode, the specific process module monitoring mode, the configuration information self-recovery monitoring mode and the process module full monitoring mode, so as to determine a more reasonable first monitoring mode according to the attributes of the monitoring data, so as to facilitate the subsequent accurate positioning of the problems of the vehicle-mounted software according to the first monitoring mode.

[0098] In some embodiments of the present application, based on the types of vehicle-mounted software corresponding to each of the multiple monitoring data and the preset priority order of the monitoring data of each type of vehicle-mounted software, determining the target monitoring mode from each first monitoring mode may include: sorting the first monitoring modes of the monitoring data corresponding to each type of vehicle-mounted software according to the types of vehicle-mounted software corresponding to each of the multiple monitoring data and the preset priority order to obtain a monitoring mode sorting result; and determining the target monitoring mode based on the monitoring mode sorting result.

[0099] In some embodiments, the types of vehicle-mounted software include vehicle-mounted operating systems, vehicle-mounted application software and monitoring systems. The preset priority order from high to low can be: monitoring data of the vehicle-mounted system, monitoring data of the vehicle-mounted application software, and monitoring data of the monitoring system. This preset priority can ensure that the response priority to the vehicle-mounted system is the highest, thereby providing the prerequisite for the stable operation of the monitoring system.

[0100] In some embodiments, the first monitoring mode corresponding to the monitoring data belonging to the vehicle-mounted system can be arranged in the first place, the first monitoring mode corresponding to the monitoring data belonging to the vehicle-mounted application software can be arranged in the middle position, and the first monitoring mode belonging to the monitoring system can be arranged at the end, so as to obtain the sorting result of the monitoring mode.

[0101] In some embodiments, the first monitoring mode ranked first in the monitoring mode sorting result can be determined as the target monitoring mode. The target monitoring mode may be the first monitoring mode corresponding to the monitoring data belonging to the vehicle-mounted system, may be the first monitoring mode corresponding to the monitoring data belonging to the vehicle-mounted application software, or may be the first monitoring mode belonging to the monitoring system.

[0102] According to the above-mentioned technical means, by sorting the first monitoring modes of the monitoring data corresponding to each type of vehicle-mounted software according to the vehicle-mounted software types corresponding to multiple monitoring data and the preset priority order, and determining the target monitoring mode based on the obtained monitoring mode sorting result, the target monitoring mode finally obtained can be matched with the priority of the vehicle-mounted software monitoring data, so that in the subsequent process of monitoring the vehicle-mounted software based on the target monitoring mode, the fault point of the vehicle-mounted software can be located more accurately.

[0103] In some embodiments of the present application, the process of creating a preset correspondence between monitoring data attribute categories and monitoring modes may include: obtaining multiple monitoring data samples; determining the reference attribute categories corresponding to each monitoring data sample, and the reference monitoring scenes corresponding to each monitoring data sample; and creating a preset correspondence between monitoring data attribute categories and monitoring modes based on the preset correspondence between each reference attribute category and each reference monitoring scene, as well as the monitoring scene and the monitoring mode.

[0104] In some embodiments, the monitoring data samples may be obtained during the testing of the monitoring system software. The monitoring data samples may include multiple monitoring data samples. The monitoring data samples may include information such as the process CPU overhead, memory overhead, number of threads, the most recently run core, priority, process IO and process scheduling of the vehicle-mounted software.

[0105] In some embodiments, reference attribute categories may include system resource load exceeding limit, forced exit, specific process CPU overhead exceeding limit, debugging signals issued by the vehicle application process module, etc., and reference monitoring scenarios may include system overload scenarios, problem location scenarios, system abnormal downtime scenarios and real vehicle testing scenarios, etc.

[0106] In some embodiments, the monitoring data samples may be classified into different reference attribute categories according to the attributes of the monitoring data samples, and the monitoring data samples and source information of the monitoring data samples may be analyzed to determine the reference monitoring scenarios corresponding to the respective monitoring data samples.

[0107] In some embodiments, there is a one-to-one correspondence between the monitoring scene and the monitoring mode in the preset correspondence between the monitoring scene and the monitoring mode, and the reference monitoring scene of the monitoring data sample of the same reference attribute category is also consistent, that is, the reference attribute category and the reference monitoring scene have a one-to-one correspondence. Therefore, the one-to-one correspondence between the reference attribute category and the reference monitoring scene, and the one-to-one correspondence between the monitoring scene and the monitoring mode can be combined to determine the monitoring mode corresponding to the monitoring data attribute category, thereby obtaining the preset correspondence between the monitoring data attribute category and the monitoring mode.

[0108] According to the above-mentioned technical means, by determining the reference attribute categories and reference control scenarios corresponding to the monitoring data samples, and based on the correspondence between the reference attribute categories and the reference monitoring scenarios, and the preset correspondence between the monitoring scenarios and the monitoring modes, the mapping relationship between the monitoring data attribute categories and the monitoring modes is obtained, so that in the subsequent process of monitoring the vehicle-mounted software, the target monitoring mode can be quickly determined according to the mapping relationship.

[0109] In an embodiment of the present application, the monitoring data of the vehicle-mounted software in operation and the current monitoring mode corresponding to the vehicle-mounted software are obtained; based on the attribute category of the monitoring data and the preset correspondence between the attribute category of the monitoring data and the monitoring mode, the target monitoring mode corresponding to the monitoring data is determined; if the current monitoring mode and the target monitoring mode are different, the current monitoring mode is switched to the target monitoring mode to monitor the resource information of the vehicle-mounted software based on the target monitoring mode. In this way, through the attribute category of the monitoring data of the vehicle-mounted software and the preset correspondence between the attribute category of the monitoring data and the monitoring mode, a target monitoring mode that is more suitable for the vehicle-mounted software can be determined. Further, by switching the current monitoring mode to the target monitoring mode, the reasonable allocation of system resources of the monitoring system software can be achieved, so that the detailed information of the abnormality or failure of the vehicle-mounted software can be accurately located, and the fault diagnosis accuracy of the vehicle-mounted software can be improved.

[0110] Next, the implementation process of the application embodiment in the actual application scenario is introduced.

[0111] like Figure 2 As shown in FIG. 1 , a schematic diagram of the structure of a monitoring system based on a smart driving vehicle controller software platform provided by the present application is shown in FIG. Figure 2 As shown, the monitoring system 200 based on the intelligent driving vehicle controller software platform includes: a function acquisition module 201, an analysis module 202, a scene adaptation module 203 and a configuration module 204.

[0112] The function acquisition module 201 mainly provides two functions. One is to realize the collection of system resources including but not limited to basic system information, disk information, network information, IO information and process module information according to the configuration; the other is to format and compress the collected data and output it to the log and to the host computer through the network interface.

[0113] The analysis module 202 mainly provides two functions. One is to mark and alarm the abnormalities in the monitoring system itself and the monitoring data, such as memory leaks in a process module; the other is to feed back the marked abnormal data to the scene adaptation module 203 in the form of signals.

[0114] The scene adaptation module 203 mainly provides three functions. The first is to provide an interface for receiving the dynamic adjustment signal sent internally, and parse it into concrete readable data according to the relevant structure; the second is to generate a scene identifier after calculating the parsed data according to a certain weight, and map it with the program monitoring mode; the third is to output configuration information to the configuration module 204. When the scene identifier is generated and matched to the corresponding mode, the monitoring system configuration information in the mode will be released to the configuration module 204.

[0115] The configuration module 204 mainly provides two functions. One is to provide a configuration query interface to the function acquisition module 201, and the other is to receive configuration information input by the host computer through the network interface, including configuration files or configuration messages, and after receiving the configuration information input by the internal scene adaptation module 203, set the polling cycle, specify the CPU or memory threshold information of the process module information, and the relevant values ​​such as the sub-module monitoring switch.

[0116] The present application embodiment provides a method for fully monitoring thread resources, such as Figure 3 As shown, the method includes:

[0117] S301, start the monitoring system.

[0118] After the monitoring system is started, the monitoring system is initialized, reads the persistent storage configuration information file, and selectively configures the monitoring system based on the current system startup scenario.

[0119] S302. Obtain a full process mapping table (equivalent to the "information table" in other embodiments).

[0120] The full process mapping table includes all process modules on the intelligent driving controller software platform equipped with the example system, and traverses all process PIDs and process names in the virtual file system of the controller system kernel to form a mapping table of process PIDs and process names. The number of monitoring times can also be monitored later. When the specified number of monitoring times is reached, the monitoring log file is fragmented to see if it exceeds the limit, and the process mapping tables of designated and non-designated modules are updated.

[0121] S303. Divide the process module into designated processes (equivalent to the "first process module" in other embodiments) and non-designated processes (equivalent to the "second process module" in other embodiments) according to the information in the current configuration module, and insert the designated process into the designated process array, and insert the non-designated process into the non-designated process array.

[0122] Function acquisition module 301 can actively obtain the mapping table of all process module PIDs and process names, and split it into designated and non-designated module process mapping tables according to the configuration information obtained in step S301; if the controller software contains a designated process, it will be matched in the full process mapping table, and if a match is found, the corresponding PID will be inserted into the designated process array, and the rest will be inserted into the non-designated process array. If the designated process is not included, the designated process array is empty.

[0123] S304: Determine whether the specified process array element is 0.

[0124] If it is 0, go to step S305A; otherwise, go to step S305.

[0125] S305A: Monitor and obtain data queue 1 based on the first threshold strategy.

[0126] S305B, traverse and obtain process module resource monitoring data according to the elements in the designated and non-designated process arrays.

[0127] S306B: Determine whether the currently acquired process is a designated process.

[0128] If the currently acquired process is a non-specified process, proceed to step S307B; otherwise, proceed to step S308B.

[0129] S307B: Monitor based on the second threshold strategy to obtain data queue 2.

[0130] S308B: Monitor based on the third threshold strategy to obtain data queue 3.

[0131] S309: Integrate data queue 1, data queue 1 and data queue 3, and transfer them to the data log or send them to the host computer through the network interface.

[0132] like Figure 4 As shown, the first threshold strategy sub-process includes:

[0133] S401, obtaining the system's current process module resource monitoring data.

[0134] The resource monitoring data includes but is not limited to information such as process CPU overhead, memory overhead, number of threads, most recently run core, priority, process IO and process scheduling.

[0135] S402. Determine whether the CPU overhead and memory overhead of the current process module are greater than the corresponding full CPU overhead threshold and memory overhead threshold of the first stage (equivalent to the "first resource overhead threshold" in other embodiments).

[0136] If yes, go to step S403 to step S406; otherwise, go to step S407.

[0137] S403: Obtain thread resource monitoring data under the current process module.

[0138] Thread resource monitoring data includes but is not limited to thread CPU overhead, memory overhead, priority and other information.

[0139] S404: Determine whether the CPU overhead of each thread of the current process module is greater than the full CPU overhead threshold of the second stage (equivalent to the “second resource overhead threshold” in other embodiments).

[0140] If yes, execute step S405; otherwise, execute step S406.

[0141] S405 , transferring the process module resource data to data queue 1 .

[0142] In the data queue 1, it can be marked whether the thread resource monitoring data hit in step S404 is included.

[0143] S406: Transfer the process non-thread resource data to data queue 1.

[0144] S407: discard the current process resource monitoring data.

[0145] like Figure 5 As shown, the second threshold strategy sub-process includes:

[0146] S501. Obtain monitoring data of current non-specified process module resources.

[0147] The monitoring data includes but is not limited to information such as process CPU overhead, memory overhead, number of threads, most recently run core, priority, process IO and process scheduling.

[0148] S502: Determine whether the CPU and memory overhead data of the current process module are greater than the corresponding full process CPU and memory overhead thresholds.

[0149] If yes, proceed to step S503, otherwise the process module resource monitoring data is discarded.

[0150] S503: The current process resource monitoring data is labeled as a non-specified process, and transferred to data queue 2.

[0151] The process resource monitoring data of this step does not include thread resource monitoring data.

[0152] like Figure 6 As shown, the third threshold strategy sub-process includes:

[0153] S601. Obtain resource monitoring data of the currently specified process module.

[0154] The resource monitoring data of the currently specified process module includes but is not limited to process CPU overhead, memory overhead, number of threads, most recently run core, priority, process IO, and process scheduling information.

[0155] S602: Determine whether the CPU and memory overhead data of the current process module are greater than the first-stage CPU and memory overhead thresholds of the corresponding current designated process.

[0156] If so, proceed to steps S603 to S606; otherwise, the process module resource monitoring data is discarded.

[0157] S603: Obtain all thread resource monitoring data of the current process.

[0158] The resource monitoring data of all threads under the current process includes but is not limited to thread CPU overhead, memory overhead, priority and other information.

[0159] S604: Determine whether the CPU overhead of all threads of the current process module is greater than the second-stage thread CPU overhead threshold of the current specified process.

[0160] If yes, execute step S605; otherwise, discard the thread resource monitoring data.

[0161] S605, transferring the thread resource data in the process module name to the data queue 3.

[0162] In the data queue 3, it can be marked whether the thread resource monitoring data hit in step S604 is included.

[0163] S606, transferring the process no-thread information to data queue 3.

[0164] In certain specific scenarios, in order to reasonably allocate the resources of the monitoring system, reduce the pressure on the controller system, and more accurately preliminarily locate the time point when the abnormality or failure occurs and the detailed information corresponding to the time point, and provide the greatest help for the deep positioning of the business development module, this embodiment also provides a scenario-based adaptive monitoring mode switching method, which analyzes the monitoring data, determines the scene change, and sends a dynamic adjustment signal to switch the monitoring system mode. In this method, the scene change can be determined by the monitoring system status, the overall CPU overhead in the monitoring data, the memory overhead, the specific process changes, and the external application signal. Figure 7 As shown, the method includes:

[0165] S701: Obtain a current input signal and classify the input signal.

[0166] The current input signals include system signals and application signals. The signals mainly include CPU and memory overruns, abnormal system downtime, and signals from external applications sent by the monitoring system.

[0167] S702: Perform scene matching based on the signal classification result and the mapping relationship between the signal category and the scene.

[0168] The signal is mapped to the specified scene through preset rule matching. The signal matching rules can be manually configured by the user and can be elastically expanded.

[0169] For example, the signal matching rule is as follows: Figure 8As shown, after obtaining the monitoring signal 800, it can be determined whether the monitoring system log has a controller system resource load threshold exceeding signal 801A. The signal generation condition is that one or more of the system CPU, network IO, disk information and memory overhead exceeds the preset threshold. If the signal exists, it is matched to the system overload scenario 801B, and the corresponding scenario signal 1 801C is output; it is determined whether there is a designated business process signal trigger 802A. When one or more processes fail, since their business working cycle is less than the monitoring system polling collection cycle, the real-time overhead of the business process cannot be determined. Based on this, the business process is supported to send a debugging signal. If the signal exists, it is matched to the problem location scenario 802B, and the corresponding scenario signal 2 802C is output; when the monitoring system receives a kill-9 signal 803A or other forced exit signal, it is matched to the system abnormal downtime scenario 803B, and the corresponding scenario signal 3 803C is output; when the monitoring system detects that the threshold of the designated business process resources (the CPU of a monitored process, the CPU corresponding to each process, and the basic CPU of the operating system) exceeds the limit 804A, the limit threshold indicates that the vehicle enters the full-function operation state. If the signal exists, it is matched to the real vehicle test scenario 804B, and the corresponding scenario signal 4 804C is output. The priority of the signal scene output may be determined according to the signal source. In this embodiment, the signal scene output may be executed according to the priority of system signal>application signal>monitoring system signal.

[0170] S703: dynamically arrange modes according to different scenarios, and obtain a mapping table of the relationship between scenarios and modes.

[0171] It can map to different modes according to the signal scenario, including minimum set mode, self-recovery mode, full mode and high frequency mode, and also supports expansion. It can dynamically adjust the scene according to the signal sent by the self-diagnosis module of the application or the signal actively input from the outside world; it can map to different modes according to the signal in the scene.

[0172] Each mode corresponds to a different policy configuration. For example, the relationship between the monitoring mode and the policy configuration is as follows: Fig. 9As shown, the scenario identifiers are mapped to different modes. In this embodiment, the minimum set mode 901A is mapped according to the system overload scenario (equivalent to the "configuration module monitoring mode" in other embodiments), corresponding to scenario identifier 1:: Mode 1 901A; the system abnormal shutdown restart is mapped to the self-recovery mode 902A (equivalent to the "configuration information self-recovery monitoring mode" in other embodiments), corresponding to scenario identifier 2:: Mode 2 902B; the problem location scenario is mapped to the high-frequency mode 903A (equivalent to the "specific process module monitoring mode" in other embodiments), corresponding to scenario identifier 3:: Mode 3 903B; the actual vehicle or bench test scenario is mapped to the full mode 904A (equivalent to the "process module full monitoring mode" in other embodiments), corresponding to scenario identifier 4:: Mode 4 904B. Among them, in the minimum set mode 901A, only the function 901C of the configuration module is retained, that is, all the functional modules of the monitoring system except the configuration module are in a suspended state; in the self-recovery mode 902A, the monitoring system restores the last configuration strategy 902C, which is the monitoring configuration at the last run; in the full mode 903A, all functional collection modules are turned on 903C, that is, all monitoring configurations are turned on, including but not limited to system basic information, network, IO, disk, scheduling and thread resource information. In the high-frequency mode 904A, the data collection cycle 904C is shortened, and the business process is specified to trigger the corresponding monitoring cycle, while the monitoring of other processes is silent to reduce resource overhead.

[0173] S704: Output the scene-mode relationship mapping table to the configuration module.

[0174] After the relationship mapping table is output to the configuration module, the configuration module can be triggered to work, thereby switching the monitoring system working mode.

[0175] The present application embodiment provides a vehicle-mounted software monitoring device, Fig.10 A schematic diagram of the structure of a vehicle-mounted software monitoring device provided in an embodiment of the present application is shown in FIG. Fig.10 As shown, the vehicle-mounted software monitoring device 1000 includes:

[0176] A first acquisition module 1001 is used to acquire monitoring data of the vehicle-mounted software in operation and a current monitoring mode for the vehicle-mounted software;

[0177] A first determination module 1002 is used to determine a target monitoring mode corresponding to the monitoring data based on the attribute category of the monitoring data and a preset correspondence between the attribute category of the monitoring data and the monitoring mode;

[0178] The first switching module 1003 is used to switch the current monitoring mode of the vehicle-mounted software to the target monitoring mode if the current monitoring mode and the target monitoring mode are different, so as to monitor the resource information of the vehicle-mounted software based on the target monitoring mode.

[0179] In some embodiments, the monitoring data includes multiple items, and the multiple monitoring data correspond to multiple attribute categories; the first determining module 1002 includes:

[0180] A first determination submodule, configured to determine a first monitoring mode corresponding to each type of monitoring data based on the attribute categories corresponding to each of the plurality of monitoring data and a preset correspondence between the attribute categories of the monitoring data and the monitoring mode;

[0181] The second determination submodule is used to determine the target monitoring mode from each first monitoring mode based on the vehicle software types corresponding to the multiple monitoring data and the preset priority order of each type of vehicle software monitoring data.

[0182] In some embodiments, the monitoring mode includes a configuration module monitoring mode, a specific process module monitoring mode, a configuration information self-recovery monitoring mode, and a process module full monitoring mode; the first determination submodule includes:

[0183] A first determining unit, configured to determine, if the reference monitoring data is of a first attribute category, based on the preset corresponding relationship, that the first monitoring mode corresponding to the reference monitoring data is a configuration module monitoring mode; the reference monitoring data is any one of the plurality of monitoring data;

[0184] a second determining unit, configured to determine, if the reference monitoring data is of a second attribute category, based on the preset corresponding relationship, that the first monitoring mode corresponding to the reference monitoring data is a specific process module monitoring mode;

[0185] A third determining unit, configured to determine, if the reference monitoring data is of a third attribute category, based on the preset corresponding relationship, that the first monitoring mode corresponding to the reference monitoring data is a configuration information self-recovery monitoring mode;

[0186] The fourth determination unit is used to determine, if the reference monitoring data is of a fourth attribute category, based on the preset corresponding relationship, that the first monitoring mode corresponding to the reference monitoring data is a full monitoring mode of the process module.

[0187] In some embodiments, the second determining submodule includes:

[0188] a sorting unit, configured to sort the first monitoring modes of the monitoring data corresponding to each type of vehicle-mounted software according to the vehicle-mounted software types corresponding to the plurality of monitoring data and the preset priority order, to obtain a monitoring mode sorting result; the vehicle-mounted software types include vehicle-mounted operating systems, vehicle-mounted application software, and monitoring systems;

[0189] A fifth determination unit is used to determine the target monitoring mode based on the monitoring mode sorting result.

[0190] In some embodiments, the vehicle-mounted software monitoring device 1000 further includes:

[0191] A second acquisition module is used to acquire multiple monitoring data samples;

[0192] A second determination module is used to determine the reference attribute category corresponding to each monitoring data sample, and the reference monitoring scene corresponding to each monitoring data sample; the reference monitoring scenes corresponding to monitoring data samples of the same reference attribute category are the same;

[0193] The first creation module is used to create a preset correspondence between the monitoring data attribute category and the monitoring mode according to each reference attribute category and each reference monitoring scene, and a preset correspondence between the monitoring scene and the monitoring mode.

[0194] In some embodiments, the first acquisition module 1001 includes:

[0195] A first acquisition submodule is used to acquire an information table of each process module of the vehicle-mounted software; the information table includes identification information of each process module;

[0196] a division submodule, for dividing each process module into a first process module and a second process module based on the monitoring configuration information and the identification information; the first process module does not include the process module of the vehicle-mounted system, and the second process module includes the process module of the vehicle-mounted system;

[0197] a second acquisition submodule, configured to acquire first monitoring data of the first process module based on a first monitoring strategy, and acquire second monitoring data of the second process module based on a second monitoring strategy; the first monitoring strategy includes monitoring resource information of threads corresponding to the process modules, and the second monitoring strategy does not include monitoring resource information of threads corresponding to the process modules;

[0198] The third acquisition submodule is used to obtain the monitoring data of the vehicle-mounted software based on the first monitoring data and the second monitoring data.

[0199] In some embodiments, the second acquisition submodule includes:

[0200] A first acquisition unit, configured to acquire first resource overhead data corresponding to the first process module;

[0201] A second acquisition unit, configured to acquire second resource overhead data of a thread corresponding to the first process module if the first resource overhead data is greater than a first resource overhead threshold;

[0202] A sixth determination unit is configured to determine the first resource overhead data and the second overhead data as the first monitoring data if the second resource overhead data is greater than a second resource overhead threshold.

[0203] In some embodiments, the second acquisition submodule includes:

[0204] A third acquisition unit, used to acquire third resource overhead data corresponding to the second process module;

[0205] A seventh determination unit is configured to determine the third resource overhead data as the second monitoring data if the third resource overhead data is greater than the first resource overhead threshold.

[0206] It should be noted that the description of the vehicle software monitoring device in the embodiment of the present application is similar to the description of the corresponding vehicle software monitoring method embodiment described above, and has similar beneficial effects as the method embodiment, so it is not repeated. For technical details not disclosed in this embodiment, please refer to the description of the method embodiment of the present application for understanding.

[0207] It should be noted that in the embodiment of the present application, if the above-mentioned vehicle-mounted software monitoring method is implemented in the form of a software function module and sold or used as an independent product, it can also be stored in a computer-readable storage medium. Based on such an understanding, the technical solution of the embodiment of the present application can be essentially or the part that contributes to the relevant solution can be embodied in the form of a software product, which is stored in a storage medium, including a number of instructions to enable a computer device (which can be a personal computer, a server, or a network device, etc.) to execute all or part of the methods of each embodiment of the present application. The aforementioned storage medium includes: various media that can store program codes, such as a U disk, a mobile hard disk, a read-only memory (ROM), a disk or an optical disk. In this way, the embodiment of the present application is not limited to any specific combination of hardware and software.

[0208] Accordingly, an embodiment of the present application provides a computer-readable storage medium on which a computer program is stored. When the computer program is executed by a processor, the vehicle-mounted software monitoring method provided in the above embodiment is implemented.

[0209] Fig.11A schematic diagram of the composition structure of a vehicle-mounted software monitoring device provided in an embodiment of the present application is as follows: Fig.11 As shown, the vehicle software monitoring device 1100 includes: a memory 1101, a processor 1102, a communication interface 1103 and a communication bus 1104. The memory 1101 is used to store executable vehicle software monitoring instructions; the processor 1102 is used to execute the executable vehicle software monitoring instructions stored in the memory 1101 to implement the vehicle software monitoring method provided in the above embodiment.

[0210] The description of the above vehicle-mounted software monitoring device embodiment is similar to the description of the above method embodiment, and has similar beneficial effects as the method embodiment. For technical details not disclosed in the vehicle-mounted device embodiment of this application, please refer to the description of the method embodiment of this application for understanding.

[0211] It should be noted that, in this article, the term "comprises" or any other variant thereof is intended to cover non-exclusive inclusion, so that a process, method, article or device including a series of elements includes not only those elements, but also includes other elements not explicitly listed, or also includes elements inherent to such process, method, article or device. In the absence of further restrictions, an element defined by the sentence "comprises at least one ..." does not exclude the existence of other identical elements in the process, method, article or device including the element.

[0212] In the several embodiments provided in the present application, it should be understood that the disclosed devices and methods can be implemented in other ways. The device embodiments described above are only schematic. For example, the division of units is only a logical function division. There may be other division methods in actual implementation, such as: multiple units or components can be combined, or can be integrated into another system, or some features can be ignored or not executed. In addition, the coupling, direct coupling, or communication connection between the components shown or discussed can be through some interfaces, and the indirect coupling or communication connection of devices or units can be electrical, mechanical or other forms.

[0213] The units described above as separate components may or may not be physically separated, and the components displayed as units may or may not be physical units; they may be located in one place or distributed on multiple network units; some or all of the units may be selected according to actual needs to achieve the purpose of the present embodiment.

[0214] In addition, all functional units in the embodiments of the present application may be integrated into one processing unit, or each unit may be a separate unit, or two or more units may be integrated into one unit; the above-mentioned integrated units may be implemented in the form of hardware or in the form of hardware plus software functional units.

[0215] A person of ordinary skill in the art can understand that: all or part of the steps of implementing the above-mentioned method embodiment can be completed by hardware related to program instructions, and the aforementioned program can be stored in a computer-readable storage medium. When the program is executed, it executes the steps of the above-mentioned method embodiment; and the aforementioned storage medium includes: various media that can store program codes, such as mobile storage devices, ROM, disks or optical disks.

[0216] Alternatively, if the above-mentioned integrated unit of the present application is implemented in the form of a software function module and sold or used as an independent product, it can also be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the embodiment of the present application can essentially or in other words, 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 and includes several instructions for a product to execute all or part of the methods of each embodiment of the present application. The aforementioned storage medium includes: various media that can store program codes, such as mobile storage devices, ROMs, magnetic disks, or optical disks.

[0217] The above are only implementation methods of the present application, but the protection scope of the present application is not limited thereto. Any technical object familiar with the technical field can be easily thought of within the technical scope disclosed in the present application. Changes or substitutions should be included in the protection scope of the present application. Therefore, the protection scope of the present application shall be based on the protection scope of the claims.

Claims

1. A vehicle software monitoring method, characterized in that: include: Acquire monitoring data of vehicle-mounted software in operation and a current monitoring mode for the vehicle-mounted software; Determine the target monitoring mode corresponding to the monitoring data based on the attribute category of the monitoring data and the preset correspondence between the attribute category of the monitoring data and the monitoring mode; If the current monitoring mode and the target monitoring mode are different, the current monitoring mode is switched to the target monitoring mode to monitor the resource information of the vehicle-mounted software based on the target monitoring mode.

2. The method according to claim 1, characterized in that The monitoring data includes a plurality of monitoring data, and the plurality of monitoring data corresponds to a plurality of attribute categories; the determining the target monitoring mode corresponding to the monitoring data based on the attribute category of the monitoring data and the preset correspondence between the attribute category of the monitoring data and the monitoring mode includes: Determine the first monitoring mode corresponding to each type of monitoring data based on the attribute categories corresponding to each of the plurality of monitoring data and the preset correspondence between the attribute categories of the monitoring data and the monitoring mode; Based on the types of vehicle-mounted software corresponding to the multiple monitoring data, and the preset priority order of various types of vehicle-mounted software monitoring data, the target monitoring mode is determined from each first monitoring mode.

3. The method according to claim 2, characterized in that The monitoring modes include configuration module monitoring mode, specific process module monitoring mode, configuration information self-recovery monitoring mode and process module full monitoring mode; The method of determining the first monitoring mode corresponding to each type of monitoring data based on the attribute categories corresponding to each of the plurality of monitoring data and the preset correspondence between the attribute categories of the monitoring data and the monitoring mode comprises: If the reference monitoring data is of the first attribute category, based on the preset corresponding relationship, determining that the first monitoring mode corresponding to the reference monitoring data is the configuration module monitoring mode; the reference monitoring data is any one of the multiple monitoring data; If the reference monitoring data is of the second attribute category, based on the preset corresponding relationship, determining that the first monitoring mode corresponding to the reference monitoring data is a specific process module monitoring mode; If the reference monitoring data is of the third attribute category, based on the preset corresponding relationship, determining that the first monitoring mode corresponding to the reference monitoring data is a configuration information self-recovery monitoring mode; If the reference monitoring data is of the fourth attribute category, based on the preset corresponding relationship, it is determined that the first monitoring mode corresponding to the reference monitoring data is the full monitoring mode of the process module.

4. The method according to claim 2, characterized in that: The determining the target monitoring mode from each first monitoring mode based on the vehicle software types corresponding to each of the plurality of monitoring data and the preset priority order of the monitoring data of each type of vehicle software includes: According to the vehicle software types corresponding to the plurality of monitoring data and the preset priority order, sorting the first monitoring modes of the monitoring data corresponding to the various vehicle software types to obtain a monitoring mode sorting result; the vehicle software types include vehicle operating systems, vehicle application software and monitoring systems; The target monitoring mode is determined based on the monitoring mode sorting result.

5. The method according to claim 1, characterized in that The process of creating the preset correspondence between the monitoring data attribute category and the monitoring mode includes: Obtain multiple monitoring data samples; Determine the reference attribute category corresponding to each monitoring data sample, and the reference monitoring scene corresponding to each monitoring data sample; the reference monitoring scenes corresponding to monitoring data samples of the same reference attribute category are the same; According to each reference attribute category and each reference monitoring scene, and the preset correspondence between the monitoring scene and the monitoring mode, a preset correspondence between the monitoring data attribute category and the monitoring mode is created.

6. The method according to any one of claims 1 to 5, characterized in that: The obtaining of monitoring data of the vehicle-mounted software in operation includes: Acquire an information table of each process module of the vehicle-mounted software; the information table includes identification information of each process module; Based on the monitoring configuration information and the identification information, the process modules are divided into a first process module and a second process module; the first process module does not include the process module of the vehicle-mounted system, and the second process module includes the process module of the vehicle-mounted system; Acquire first monitoring data of the first process module based on a first monitoring strategy, and acquire second monitoring data of the second process module based on a second monitoring strategy; the first monitoring strategy includes monitoring resource information of threads corresponding to the process modules, and the second monitoring strategy does not include monitoring resource information of threads corresponding to the process modules; Based on the first monitoring data and the second monitoring data, the monitoring data of the vehicle-mounted software is obtained.

7. The method according to claim 6, characterized in that The acquiring the first monitoring data of the first process module based on the first monitoring strategy includes: Obtaining first resource overhead data corresponding to the first process module; If the first resource overhead data is greater than a first resource overhead threshold, obtaining second resource overhead data of a thread corresponding to the first process module; If the second resource overhead data is greater than a second resource overhead threshold, the first resource overhead data and the second resource overhead data are determined as the first monitoring data.

8. The method according to claim 6, characterized in that The acquiring the second monitoring data of the second process module based on the second monitoring strategy includes: Obtaining third resource overhead data corresponding to the second process module; If the third resource overhead data is greater than the first resource overhead threshold, the third resource overhead data is determined as the second monitoring data.

9. A vehicle-mounted software monitoring device, characterized in that: include: A first acquisition module, used to acquire monitoring data of the vehicle-mounted software in operation and a current monitoring mode for the vehicle-mounted software; A first determination module, configured to determine a target monitoring mode corresponding to the monitoring data based on an attribute category of the monitoring data and a preset correspondence between the attribute category of the monitoring data and the monitoring mode; The first switching module is used to switch the current monitoring mode of the vehicle-mounted software to the target monitoring mode if the current monitoring mode and the target monitoring mode are different, so as to monitor the resource information of the vehicle-mounted software based on the target monitoring mode.

10. A vehicle-mounted software monitoring device, characterized in that: include: processor and memory; wherein, The memory is used to store a computer program that can be run on the processor; The processor is configured to execute the method according to any one of claims 1 to 8 when running the computer program.

11. A computer-readable storage medium, characterized in that: The storage medium stores computer program code, and when the computer program code is executed by a computer, the method according to any one of claims 1 to 8 is executed.

Images