Resource scheduling methods, devices, equipment and media for vehicle-mounted intrusion detection systems

Abstract

This application provides a resource scheduling method, apparatus, device, and medium for a vehicle-mounted intrusion detection system. The method includes: acquiring the thread resources required for intrusion detection by several detection modules and the upper limit of the scheduling weight of each detection module relative to the thread resources; when one or more detection modules in the post-processing stage have data to be processed, determining the number of allocable threads in real time based on the sum of the thread resources and the current thread count of one or more detection modules in the post-processing stage; determining the allocation weight of each detection module according to the number of allocable threads based on the current thread count of each detection module and its corresponding upper limit of scheduling weight; and allocating the corresponding number of threads to each detection module based on the allocation weight. This method effectively solves the problem of uneven resource allocation in vehicle-mounted intrusion detection systems and achieves the technical effect of improving intrusion detection performance without affecting the normal use of other functions.

Description

Technical Field

[0001] This application relates to the field of data processing technology, and in particular to a resource scheduling method, apparatus, equipment and medium for a vehicle-mounted intrusion detection system. Background Technology

[0002] With the development of intelligence and connectivity, automotive systems are facing increasingly serious information security problems. Intrusion detection systems are being used more and more widely in vehicle controllers. An intrusion detection system (IDS) is a technology that can protect vehicle security. Its working principle is to monitor the vehicle network, detect and intercept malicious behavior.

[0003] Although intrusion detection systems can effectively detect and block malicious behavior, they currently lack a reasonable resource scheduling scheme, resulting in an uneven distribution of system resources. They need to consume a large amount of system resources to improve the performance of security detection, which may affect the normal operation of other vehicle functions.

[0004] Therefore, how to rationally allocate intrusion detection system resources under the limited system resources of the vehicle system, so as to meet the high-performance processing of vehicle intrusion detection without affecting the normal operation of other functions, has become an urgent problem to be solved. Summary of the Invention

[0005] This application provides a resource scheduling method, apparatus, equipment, and medium for a vehicle-mounted intrusion detection system to solve the problem of uneven allocation of system resources in a vehicle-mounted intrusion detection system.

[0006] In a first aspect, this application provides a resource scheduling method for a vehicle-mounted intrusion detection system. The vehicle-mounted intrusion detection system includes several detection modules for performing different vehicle-mounted intrusion detection stages, wherein the vehicle-mounted intrusion detection stages include an initial detection stage and a post-processing stage. The method includes:

[0007] Obtain the thread resources required by the detection modules for intrusion detection and the upper limit of the scheduling weight of each detection module regarding thread resources;

[0008] When there is data to be processed in one or more detection modules in the post-processing stage, the number of available threads is determined in real time based on the sum of the thread resources and the current thread count of one or more detection modules in the post-processing stage.

[0009] The allocation weight of each detection module is determined based on the current number of threads of each of the detection modules and their corresponding upper limit of scheduling weight, according to the number of allocable threads.

[0010] Based on the allocation weight, a corresponding number of threads are allocated to each detection module. The number of threads is used to process the data to be processed by the corresponding detection module for intrusion detection.

[0011] In one embodiment, the detection module in the initial detection phase includes a preliminary detection module for collecting behavioral data; the detection module in the post-processing phase includes a secondary confirmation module for identifying whether the behavior corresponding to the behavioral data is an intrusion behavior, a data collection module for acquiring intrusion data of the intrusion behavior, and a data processing module for generating an intrusion response strategy based on the intrusion data.

[0012] In one embodiment, the vehicle intrusion detection system further includes several cache queues that are respectively connected to each detection module in the post-processing stage, and the several cache queues are respectively used to store the data to be processed in the corresponding detection module.

[0013] In one implementation, obtaining the thread resources required for the plurality of detection modules to perform intrusion detection and the upper limit of the scheduling weight of each of the plurality of detection modules regarding thread resources includes:

[0014] The scheduling weight ratio of thread resources among the detection modules is obtained based on the runtime of each of the detection modules.

[0015] Based on the aforementioned scheduling weight ratio, the thread resources required for the intrusion detection by the plurality of detection modules and the upper limit of the scheduling weight of each of the plurality of detection modules regarding thread resources are obtained.

[0016] In one implementation, determining the allocation weight of each detection module based on the current thread count of each of the plurality of detection modules and their corresponding scheduling weight upper limit according to the allocable thread count includes:

[0017] Based on the current thread count of each of the detection modules and its corresponding scheduling weight limit, it is determined whether the current thread count of each detection module has reached the thread count corresponding to the scheduling weight limit.

[0018] If the current number of threads in the detection module reaches the number of threads corresponding to the upper limit of the scheduling weight, the allocation weight of the detection module will be set to zero.

[0019] In one implementation, the upper limit of the scheduling weight of the detection module in the initial detection phase is infinite.

[0020] After obtaining the thread resources required for intrusion detection by the plurality of detection modules and the upper limit of the scheduling weight of each of the plurality of detection modules with respect to thread resources, the method further includes:

[0021] When all detection modules in the post-processing stage have no data to be processed and the sum of the current thread counts of all detection modules is zero, the corresponding number of threads is directly allocated to the detection modules in the initial detection stage based on the thread resources.

[0022] In one implementation, before allocating the corresponding number of threads to each detection module based on the allocation weight, the method further includes:

[0023] The priority of the plurality of cache queues is determined based on the processing order of the data to be processed by each detection module in the post-processing stage, wherein the processing order is determined based on the data flow direction between each detection module in the post-processing stage.

[0024] The scheduling priority of the detection modules is determined based on the priority of the cache queues.

[0025] The step of allocating a corresponding number of threads to each detection module based on the allocation weight includes: allocating a corresponding number of threads to each detection module based on the scheduling priority of the plurality of detection modules and the allocation weight.

[0026] In one embodiment, the method further includes:

[0027] When allocating the corresponding number of threads to the detection module in the initial detection phase, the number of data to be processed by the detection module in the initial detection phase is controlled based on the command bucket control algorithm.

[0028] Secondly, this application provides a resource scheduling device for a vehicle-mounted intrusion detection system. The vehicle-mounted intrusion detection system includes several detection modules for performing different vehicle-mounted intrusion detection stages, wherein the vehicle-mounted intrusion detection stages include an initial detection stage and a post-processing stage. The device includes:

[0029] The acquisition module is configured to acquire the thread resources required by the plurality of detection modules for intrusion detection and the upper limit of the scheduling weight of each of the plurality of detection modules regarding thread resources.

[0030] The first determining module is configured to determine the number of allocable threads in real time based on the sum of the thread resources and the current thread count of the one or more detection modules in the post-processing stage when there is data to be processed in one or more detection modules in the post-processing stage.

[0031] The second determining module is configured to determine the allocation weight of each detection module based on the current number of threads of each of the plurality of detection modules and their corresponding scheduling weight upper limit according to the number of allocable threads;

[0032] The allocation module is configured to allocate a corresponding number of threads to each detection module based on the allocation weight. The number of threads is used to process the data to be processed by the corresponding detection module for intrusion detection.

[0033] Thirdly, an electronic device is provided, comprising: a processor, and a memory communicatively connected to the processor;

[0034] The memory stores computer-executed instructions;

[0035] The processor executes computer execution instructions stored in the memory to implement the resource scheduling method of the vehicle intrusion detection system.

[0036] Fourthly, a computer-readable storage medium is provided, wherein computer-executable instructions are stored in the computer-readable storage medium, and the computer-executable instructions, when executed by a processor, are used to implement the resource scheduling method of the vehicle-mounted intrusion detection system.

[0037] The resource scheduling method, apparatus, device, and medium for a vehicle-mounted intrusion detection system provided in this application obtain the thread resources required for intrusion detection by several detection modules and the upper limit of the scheduling weight of each detection module regarding the thread resources. When one or more detection modules in the post-processing stage have data to be processed, the number of allocable threads is determined in real time based on the sum of the thread resources and the current thread count of one or more detection modules in the post-processing stage. The allocation weight of each detection module is determined according to the number of allocable threads based on the current thread count of each detection module and its corresponding upper limit of scheduling weight. The corresponding number of threads is allocated to each detection module based on the allocation weight. This can effectively solve the problem of uneven resource allocation in vehicle-mounted intrusion detection systems and achieve the technical effect of improving intrusion detection performance without affecting the normal use of other functions. Attached Figure Description

[0038] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0039] Figure 1 This is a schematic diagram of a possible scenario provided for an embodiment of this application;

[0040] Figure 2 A flowchart illustrating a resource scheduling method for a vehicle-mounted intrusion detection system provided in this application embodiment;

[0041] Figure 3 This is a possible architecture diagram of the vehicle intrusion detection system in the embodiments of this application;

[0042] Figure 4A flowchart illustrating another resource scheduling method for a vehicle-mounted intrusion detection system provided in this application embodiment;

[0043] Figure 5 A flowchart illustrating another resource scheduling method for a vehicle-mounted intrusion detection system provided in this application embodiment;

[0044] Figure 6a This is one example diagram of the dynamic weighted scheduling model corresponding to the resource scheduling method of the vehicle intrusion detection system provided in the embodiments of this application;

[0045] Figure 6b This is an example diagram of a pipeline model in related technologies;

[0046] Figure 6c This is an example diagram of a fully parallel model in related technologies;

[0047] Figure 6d The second example diagram shows the dynamic weighted scheduling model corresponding to the resource scheduling method of the vehicle intrusion detection system provided in the embodiments of this application.

[0048] Figure 7 This is a schematic diagram of the resource scheduling device of the vehicle intrusion detection system provided in the embodiments of this application;

[0049] Figure 8 A schematic diagram of an electronic device provided in an embodiment of this application;

[0050] Figure 9 This is a block diagram illustrating a terminal device in an exemplary embodiment of this application.

[0051] The accompanying drawings illustrate specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to particular embodiments. Detailed Implementation

[0052] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0053] The following explanation of the embodiments of this application in conjunction with application scenarios illustrates that the resource scheduling method of the vehicle intrusion detection system provided in this application can be applied to autonomous driving application scenarios, and more specifically, to autonomous driving application scenarios based on vehicle cloud computing. For example, the execution subject of the method provided in this application can be an intelligent vehicle, and more specifically, for example, the domain controller or central controller of the intelligent vehicle. The following description uses the domain controller as the execution subject of the method provided in this application. Figure 1 This is a schematic diagram of a resource scheduling method for a vehicle-mounted intrusion detection system provided in an embodiment of this application, as shown below. Figure 1 As shown, the domain controller of the intelligent vehicle 101 can actively detect whether there have been any changes to the running programs and running configurations. The running programs include navigation programs, autonomous driving programs, etc., and the running configurations are the configuration files generated by the intelligent vehicle 101 during operation. Furthermore, after the domain controller determines that the running programs and running configurations have been changed, it collects possible suspected intrusion behaviors. Suspected intrusion behaviors are behaviors such as changes to the running programs and running configurations, such as the behavior of tampering with the autonomous driving program. There is behavioral data corresponding to suspected intrusion behaviors. Furthermore, the domain controller processes the suspected intrusion behaviors to determine whether the vehicle domain controller has experienced in-vehicle intrusion.

[0054] In related technologies, the detection process for suspected intrusion typically involves an in-vehicle intrusion detection system extracting the identifier and timestamp of a new message received. Based on the identifier, the system determines the corresponding time information and then checks for anomalies in the new message according to preset detection conditions, thereby determining whether an intrusion has occurred. However, due to the limited system resources of an in-vehicle system, the aforementioned intrusion detection system does not allocate resources reasonably at each stage, easily leading to resource imbalances. This can cause some detection functions to be unable to obtain system resources to operate, or even render some functions unavailable, thus affecting the security performance of the in-vehicle system.

[0055] Current system scheduling and allocation schemes generally include serial, pipelined, and fully parallel models. The serial model uses only one thread to process one message at a time, resulting in extremely low execution efficiency. The fully parallel model allocates N threads to process N messages simultaneously, but if there are mutually exclusive shared resources, performance will drop sharply, and if too many threads are allocated, performance may even decrease instead of increase. The pipelined model divides the execution flow into multiple module stages, allocating threads according to the proportion of the total execution time for each stage, thereby minimizing the impact of the drastic performance degradation caused by mutually exclusive shared resources in the fully parallel model. For example, an intrusion detection system can be divided into four stages, with each stage's runtime proportion being 1:1:2:1. Allocating 5m threads according to m / m / 2m / m is a pipelined allocation scheme. This reduces the conflicts for accessing mutually exclusive resources to only N / 5, mitigating the performance degradation caused by accessing mutually exclusive shared resources.

[0056] While pipelined models optimize resource allocation, their requirement for thread resources to be allocated according to a proportional ratio places extremely high demands on the accuracy of estimations. Incorrect estimations can lead to insufficient thread allocation to long-running modules, ultimately reducing the overall pipeline's performance. For example, if the estimated runtime ratio for each stage is 1:1:1:1, but the actual ratio is 1:1:2:1, the allocated performance is only 50% of the optimal ratio. Conversely, allocating extra threads to modules results in wasted thread idle time. For instance, if the estimated runtime ratio for each stage is 1:1:2:1, but the actual ratio is 1:1:1:1, one thread is actually wasting time. Therefore, pipelined models place extremely high demands on the accuracy of runtime estimations, placing undue pressure on developers. Performance stability is also poor; a configuration that performs well in one scenario may perform poorly in another because the scheduling ratios at each stage cannot be adaptively adjusted.

[0057] To address the aforementioned issues, this embodiment of the vehicle intrusion detection system divides the system into an initial detection phase and a post-processing phase. During the domain controller's handling of suspected intrusion behavior, detection modules at different detection phases sequentially process the behavioral data and data derived from that data (hereinafter referred to as "data to be processed"). By acquiring the thread resources required by each detection module and the upper limit of its scheduling weight, the system determines the number of allocable threads in real time based on the sum of the current thread counts of one or more detection modules in the post-processing phase. Then, based on the current thread counts of each detection module and their corresponding upper limit of scheduling weights, the system determines the allocation weight of each detection module according to the available thread counts. This allocation weight is then used to allocate the corresponding number of threads to each detection module for processing the data to be processed. During this process, the module weights are dynamically adjusted, and thread resources are allocated to each intrusion detection module through weighted scheduling. This allows the scheduling method to adapt to the changes in each detection module, enabling the intrusion detection system to efficiently utilize the allocated thread resources, perform high-performance vehicle intrusion detection processing, effectively reduce thread resource waste in vehicle intrusion detection, and achieve a balance between reasonable resource consumption and detection efficiency.

[0058] Optionally, the intelligent vehicle 101 and the terminal device 102 are electrically connected. If an intrusion is detected in the intelligent vehicle 101, a corresponding security policy can be generated to enable the intelligent vehicle 101 to execute the security policy and reduce the occurrence of danger. Simultaneously, the intrusion detection result and corresponding process data can be sent to the terminal device 102 for data analysis, or an alarm message can be generated using the intrusion detection result and sent to the terminal device 102 for display, allowing the user to be aware of the intelligent vehicle 101's operating status in a timely manner. It is understood that the terminal device 102 may include, but is not limited to, computers, smartphones, tablets, e-book readers, Moving Picture Experts Group audio layer III (MP3) players, Moving Picture Experts Group audio layer IV (MP4) players, portable computers, in-vehicle computers, wearable devices, desktop computers, set-top boxes, smart TVs, etc.

[0059] Optionally, the vehicle intrusion detection system can also be deployed in the terminal device 102 or an external server. It collects behavioral data sent by the intelligent vehicle 101 in real time through the network, identifies possible intrusion behaviors, processes them, determines whether a vehicle intrusion has occurred, and then sends message commands to control the intelligent vehicle 101. This application embodiment does not specifically limit the deployment location of the vehicle intrusion detection system. It can be deployed inside or outside the intelligent vehicle.

[0060] The technical solution of this application and how it solves the above-mentioned technical problems will be described in detail below with reference to the accompanying drawings and specific embodiments. It should be noted that these specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments.

[0061] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, use and processing of the relevant data must comply with relevant laws, regulations and standards, and corresponding operation entry points are provided for users to choose to authorize or refuse.

[0062] Figure 2 This is a flowchart of a resource scheduling method for a vehicle intrusion detection system according to an embodiment of this application. The vehicle intrusion detection system of this embodiment includes several detection modules for performing different vehicle intrusion detection stages. The vehicle intrusion detection stages include an initial detection stage and a post-processing stage, such as... Figure 2 As shown, the resource scheduling method of the vehicle intrusion detection system provided in this embodiment includes the following steps S201-S204.

[0063] In this embodiment, the detection module in the initial detection stage includes a preliminary detection module for collecting behavioral data; the detection module in the post-processing stage includes a secondary confirmation module for identifying whether the behavior corresponding to the behavioral data is an intrusion behavior, a data collection module for acquiring intrusion data of intrusion behavior, and a data processing module for generating an intrusion response strategy based on the intrusion data.

[0064] In a feasible implementation, examples of different vehicle intrusion detection stages, their detection modules, and specific functions are shown in Table 1 below:

[0065]

[0066]

[0067] Table 1

[0068] In some embodiments, in addition to the initial detection stage and the post-processing stage, the vehicle intrusion detection stage can also add corresponding detection stages according to the actual application, such as a verification stage, which can be used to verify the data generated in the post-processing stage; correspondingly, the detection modules of the initial detection stage and the post-processing stage are not limited to the above detection modules, and corresponding detection modules can be added according to the actual application, which will not be elaborated here.

[0069] Furthermore, the vehicle-mounted intrusion detection system also includes several cache queues that are connected to each detection module in the post-processing stage, and the cache queues are used to store the data to be processed in the corresponding detection module.

[0070] In this embodiment, each detection module in the post-processing stage is connected to a corresponding cache queue. The length of the cache queue in each stage can be adaptively set according to the actual application. The cache queue can effectively limit the queue of data to be processed by each detection module in the post-processing stage, thereby controlling the resource consumption of the entire detection system.

[0071] For example, the detection module in the initial detection phase does not set up a corresponding cache queue to avoid data congestion or data loss due to excessive behavioral data. Instead, it uses a token bucket to control the behavioral data entering the initial detection phase to avoid excessive resource consumption. Figure 3 As shown, the vehicle-mounted intrusion detection system capable of dynamic weighted scheduling consists of four detection modules, three cache queues, and a token bucket. The four detection modules represent a division for handling intrusion behavior at different stages, and the three cache queues are responsible for storing messages to be processed by their respective modules. In some embodiments, the above division of detection modules can be re-divided and adjusted according to actual needs.

[0072] For example, the relationships between the various components in an intrusion detection system can be seen in Table 2 below:

[0073]

[0074]

[0075] Table 2

[0076] Step S201: Obtain the thread resources required for several detection modules to perform intrusion detection, as well as the upper limit of the scheduling weight of each detection module regarding thread resources.

[0077] In related technologies, intrusion detection systems directly occupy the system resources of the vehicle system for intrusion detection, which can easily lead to excessive resource consumption and affect the normal use of other functions of the vehicle system. In this embodiment, before performing resource scheduling, the thread resources required for intrusion detection and the scheduling weight limit of each detection module are first obtained, and the real-time resource scheduling of each detection module is performed under the thread resources and the corresponding scheduling weight limit. This improves the efficiency of intrusion detection and effectively reduces the situation of resource consumption or shortage.

[0078] As is understandable, a thread, also known as a lightweight process (LWP), is the smallest unit of program execution flow. In this embodiment, the thread resources required for intrusion detection refer to the total number of scheduled threads required for intrusion detection in the vehicle-mounted intrusion detection system.

[0079] In one implementation, to further improve intrusion detection efficiency and reduce resource consumption or shortages, thread resources and scheduling weight limits for each detection module are obtained based on the runtime of each detection module. Specifically, step S201, obtaining the thread resources required for intrusion detection by several detection modules and the scheduling weight limits for each detection module regarding thread resources, may include the following steps:

[0080] The scheduling weight ratio of thread resources among several detection modules is obtained based on the runtime of each of the several detection modules.

[0081] Based on the scheduling weight ratio, obtain the thread resources required for several detection modules to perform intrusion detection, as well as the upper limit of the scheduling weight of each detection module regarding thread resources.

[0082] In this embodiment, the runtime of the detection module can be obtained by adaptive calculation based on the initial scheduling allocation and the scheduling allocation during formal operation. For example, the runtime of each running module is estimated based on experience during the initial allocation; after formal operation, the average runtime of the module is estimated by accumulating the actual running time of each module.

[0083] In one implementation, the runtime of each detection module is obtained, and the runtime ratio of each detection module is obtained, such as the ratio 1 / W2 / W3 / W4 (1 represents the initial detection module; 2 represents the secondary confirmation module; 3 represents the data collection module; 4 represents the processing module; where the ratio of each detection module corresponding to 1 is based on the scheduling weight of the initial detection stage, and can also be expressed as W1), which is the scheduling weight ratio of each detection module.

[0084] Understandably, this embodiment uses a 1:1 ratio of weights to threads, meaning the number of threads corresponds to the number of weights. In some complex cases (where there are too many threads), the ratio can be scaled according to the scheduling weights.

[0085] In this embodiment, the calculation rule for the total number of scheduled threads can be: total number of threads = rule floor(1+W2+W3+W4)*m (floor means rounding down, m≥1) = Wt*m (Wt represents the total weight, the total number of threads in each thread group). In this embodiment, the scheduling process of one thread group with m=1 is taken as an example. In some embodiments, the threads can be divided into m thread groups, each thread group is scheduled separately, and the thread groups are scheduled independently.

[0086] In this embodiment, the upper limit of the scheduling weight W for each detection module is... i_max The calculation rule can be to add a weight to the current scheduling weight, such as calculating the upper limit of the scheduling weight of each module according to the ratio 1:1:2.3:1:X / 2 / 3 / 2 (X means no limit), as follows:

[0087] W 1_max =X (X represents no restriction; i=1)

[0088] W i_max =ceil(W i +1)(ceil indicates rounding up; i!=1)

[0089] Understandably, in this embodiment, the upper limit of the scheduling weight of the initial detection module can be set to infinity. This allows all thread resources to be scheduled in the initial detection module when other detection modules have no data to process, enabling real-time and efficient detection of received behavioral data. When the data enters the detection modules in the post-processing stage, the available threads are then scheduled in real time, achieving the technical effect of efficiently utilizing limited thread resources. In some embodiments, where there is more than one detection module in the initial detection stage, the upper limit of the scheduling weight of all modules in the initial detection stage can be set to X.

[0090] Understandably, the maximum scheduling weight for each detection module in the post-processing stage is one more weight (thread). In one implementation, this can be considered in conjunction with the scheduling priority of each detection module. For example, the prerequisite for giving a higher scheduling priority is that there is a message backlog in the current module's cache queue. Only by allocating more resources to the tail module of the process (such as the data processing module or the data collection module) can the tail process be accelerated. Otherwise, the thread will be used for the front module of the process (such as the initial detection module), resulting in more messages backlog waiting for the tail process. At the same time, too many resources should not be allocated to the front module of the process, otherwise, threads will be concentrated in the tail module or the front module threads, causing the pipeline to not be completely staggered. Therefore, this embodiment allows the tail module to occupy one more thread when there is a backlog. In some embodiments, the number of additional weights can also be adjusted according to the actual thread resources of the application.

[0091] This embodiment obtains the thread resources and corresponding scheduling weight limits required by the intrusion detection system to perform intrusion detection based on the operating overhead of each detection module. This can effectively improve the detection efficiency of the intrusion detection system without consuming too many thread resources.

[0092] Step S202: When there is data to be processed in one or more detection modules in the post-processing stage, the number of available threads is determined in real time based on the sum of thread resources and the current number of threads of one or more detection modules in the post-processing stage.

[0093] In this embodiment, considering that data accumulation in the tail modules of data processing during the entire intrusion detection process is more likely to cause the entire intrusion detection process to stagnate, leading to system operational difficulties, this embodiment dynamically allocates thread resources by determining the number of allocable threads based on the sum of the total number of threads and the current thread count of one or more detection modules in the post-processing stage when there is data to be processed in one or more detection modules in the post-processing stage. The number of one or more detection modules in the post-processing stage can be determined based on the number of modules in the post-processing stage and / or the total number of threads. For example, if there are few modules in the post-processing stage, such as the three detection modules in the post-processing stage exemplified in this embodiment, the one or more detection modules are determined to be two: a data collection module and a data processing module. In some embodiments, other methods may also be used, which will not be elaborated here.

[0094] In the above process, determining the number of allocable threads is equivalent to treating the initial inspection module and the secondary confirmation module (or simply the initial inspection module) as the front-end modules of the process, and the data collection module and the data processing module as the back-end modules. When there is data to be processed in the back-end modules, threads are reallocated based on the total number of threads and the threads occupied by the front-end modules. Simultaneously, it is checked whether each inspection module has reached its scheduling weight limit; inspection modules that have reached their scheduling weight limit do not participate in this resource reallocation process. This process allows for flexible and balanced scheduling of front-end and back-end resources and effectively avoids data congestion problems in the back-end modules. It can be understood that the current thread count is the number of threads at the current moment of resource scheduling.

[0095] In one implementation, the current thread resource occupancy status can be detected first to determine the number of available threads. Specifically, during the operation of the vehicle intrusion detection system, if the current total thread occupancy rate is 100%, meaning the number of threads that can be freely scheduled or are idle is 0, i.e., the total allocation weight (current available thread count) Wc ≤ 0 (Wc < 0 is usually not the case; this is to consider fault tolerance in the coding), the above process is executed to determine the number of available threads.

[0096] Step S203: Based on the current number of threads of each detection module and its corresponding scheduling weight limit, determine the allocation weight of each detection module according to the number of allocable threads.

[0097] In this embodiment, the allocation weight of each detection module is determined according to the current number of threads and the upper limit of the scheduling weight of each detection module, based on the number of allocable threads, so that dynamic weight scheduling of each detection module can be realized.

[0098] In one implementation, the allocation weight of a module whose current thread count reaches the scheduling weight limit is set to zero to avoid the corresponding module occupying too many threads, resulting in fewer schedulable thread resources for other detection modules and thus affecting the efficiency of vehicle intrusion detection. Specifically, step S203 determines the allocation weight of each detection module based on its current thread count and corresponding scheduling weight limit according to the number of allocable threads, including:

[0099] Based on the current thread count of each detection module and its corresponding scheduling weight limit, determine whether the current thread count of each detection module has reached the thread count corresponding to the scheduling weight limit.

[0100] If the current number of threads in the detection module reaches the number of threads corresponding to the upper limit of the scheduling weight, the assigned weight of the detection module will be set to zero.

[0101] For example, the number of allocable threads is 10, the upper limit of the scheduling weight of each detection module is 3 / 2 / 3 / 2, and the current number of threads of each detection module is 2 / 2 / 2 / 2. This illustrates the upper limit of the scheduling weight of the secondary confirmation module and the data processing module. The detection module with the upper limit of weight is determined to have an allocated weight of 0, and the allocated weight of other detection modules can be in a 1:1 ratio. In some embodiments, other ratios can also be set according to the actual application.

[0102] Step S204: Allocate a corresponding number of threads to each detection module based on the assigned weight. The number of threads is used to process the data to be processed by the corresponding detection module for intrusion detection.

[0103] In this embodiment, the allocation weight and the number of allocated threads are in a 1:1 ratio, that is, the allocation weight (number) is equal to the number of allocated threads. In some embodiments, the allocation weight may be different from the number of allocated threads, and the allocation weight corresponds to the proportion of the number of allocated threads.

[0104] For example, when the current total allocation weight Wc ≤ 0, the number of allocable threads is determined to be Wc = Wt - C3 - C4. All detection modules are added to the allocable list {1, 2, 3, 4}. The number of allocated threads C1 / C2 / C3 / C4 for each detection module is compared with the scheduling weight limit W1_max / W2_max / W3_max / W4_max. Modules that have reached the scheduling weight limit are removed from the allocable list. For detection modules that have not reached the scheduling weight limit, the scheduling weight is allocated proportionally. The allocable list is traversed according to the number of allocable threads, starting from the scheduling priority of each detection module from high to low (SP3>SP2>SP1) (each traversal can be based on 1 thread). The following steps are performed: if the cache queue is empty, skip it; if there is data to be processed in the cache queue, the thread is assigned to execute the corresponding detection module in the queue. In some cases, such as non-specific detection modules (with a lot of data to be processed and a large number of threads required), such as the initial detection module or the secondary confirmation module, the corresponding detection module is removed from the allocable list, and Wc = Wc - 1 is set.

[0105] In some embodiments, to further ensure the effectiveness of resource scheduling, a preset scheduling duration can be set. When the scheduling interval reaches a preset threshold, the duration ratio of each detection module is recalculated, and the scheduling weight is recalculated based on the above steps. When the scheduling interval does not reach the preset threshold, thread scheduling can continue based on the above allocation process.

[0106] Furthermore, to avoid excessive data entering the vehicle intrusion detection system and to prevent excessive thread resource consumption, this embodiment of the application incorporates a token bucket algorithm to control the amount of data entering the initial detection module. Specifically, the method may further include the following steps: when allocating a corresponding number of threads to the detection module in the initial detection phase, the token bucket control algorithm is used to control the amount of data to be processed received by the detection module in the initial detection phase.

[0107] Understandably, the token bucket algorithm is one of the most commonly used algorithms in network traffic shaping and rate limiting. Typically, the token bucket algorithm is used to control the amount of data sent over the network and allows for bursty data transmission. This embodiment uses the token bucket algorithm to control intrusion detection resource consumption, achieving a balance between resource consumption and detection performance.

[0108] In one implementation, if a thread is assigned to the initial inspection module, it performs the following steps: A. If the token bucket is insufficient, it sleeps and waits until it acquires enough tokens to pass; B. It consumes the tokens. If a thread is not assigned to the initial inspection module, it processes data according to the current actual number of tokens.

[0109] In this embodiment, dynamic weighted scheduling among detection modules effectively improves the problems of fixed thread resources in pipeline models, which make it difficult to guarantee efficient operation at each stage and lead to resource waste. By periodically collecting the runtime of each detection module, the optimal scheduling weight of each module is calculated, and the allocation ratio of each module is dynamically adjusted. In each round of scheduling, the number of threads allocated to each detection module will not exceed the optimal scheduling weight of the detection module, which can effectively ensure that each detection module operates in the optimal ratio. This enables the intrusion detection system to complete vehicle intrusion detection processing with high performance and effectively reduce the waste of thread resources in vehicle intrusion detection, achieving a balance between reasonable resource consumption and detection efficiency.

[0110] Please refer to Figure 4 , Figure 4 This is a flowchart illustrating another vehicle-mounted intrusion detection method provided in this application embodiment. Based on the above embodiment, this embodiment considers the differences in the amount of data in different detection modules during the intrusion detection stage. If the tail module processes the data faster, it will result in thread idleness. In order to further make reasonable use of thread resources, this embodiment sets the upper limit of the scheduling weight of the detection module in the initial detection stage to an infinite value. In addition to steps S201-S204 corresponding to the above embodiment, after obtaining the thread resources required by several detection modules for intrusion detection and the upper limit of the scheduling weight of each of the several detection modules regarding thread resources in step S201, step S401 is also set.

[0111] Step S401: When all detection modules in the post-processing stage have no data to be processed and the sum of the current thread counts of all detection modules is zero, directly allocate the corresponding number of threads to the detection modules in the initial detection stage based on thread resources.

[0112] For example, when scheduling thread resources, the current thread count C1 / C2 / C3 / C4 of each detection module in the thread group is first counted. If C2+C3+C4=0 and queues SP1, SP2, and SP3 are empty (no data to be processed), the scheduling preparation phase can be entered. At this time, W is set. c =0, and allocate the number of threads to the initial inspection module based on the thread resources. For example, if C1 is also 0 at this time, all thread resources can be allocated to C1. If C1 is 1 at this time, then (thread resources - 1) threads are allocated to the initial inspection module.

[0113] In this embodiment, when other detection modules have no data to process, all thread resources can be scheduled in the initial detection module to detect the received behavioral data in real time and efficiently. When the data enters each detection module in the post-processing stage, the available threads are scheduled in real time to achieve the technical effect of efficiently utilizing limited thread resources.

[0114] In some embodiments, considering that the secondary confirmation module is a module following the initial inspection module and will process data from the processing module, in order to enable the secondary confirmation module to quickly enter the processing flow, when C3+C4=0, and queues SP2 and SP3 are empty, and SP1 is not empty, one (or more) thread resources are first allocated to the secondary confirmation module, and then the remaining thread resources are allocated to the initial inspection module.

[0115] Please refer to Figure 5 , Figure 5 This is a flowchart illustrating another vehicle-mounted intrusion detection method provided in this application. Based on the above embodiments, this embodiment improves thread scheduling flexibility by determining the scheduling priority of each detection module and allocating thread counts to the detection modules according to the scheduling priority and corresponding allocation weights. This allows important modules to obtain more thread resources, thereby improving the detection performance of vehicle-mounted intrusion detection. Specifically, in addition to steps S201-S204 described above, this embodiment includes steps S501 and S502 before allocating the corresponding number of threads to each detection module based on the allocation weights in step S204, and further subdivides step S204 into step S204a.

[0116] Step S501: Determine the priority of several buffer queues based on the processing order of the data to be processed by each detection module in the post-processing stage, wherein the processing order is determined based on the data flow direction between each detection module in the post-processing stage.

[0117] Step S502: Determine the scheduling priorities of several detection modules based on the priorities of several cache queues.

[0118] Step S204a: Allocate corresponding numbers of threads to each detection module based on the scheduling priorities and allocation weights of several detection modules.

[0119] It can be understood that the data flow in this embodiment is: preliminary inspection module → secondary confirmation module → data collection module → data processing module. The priorities of the cache queues have been mentioned above, where the SP1 queue < SP2 queue < SP3 queue. In one implementation, the preliminary inspection module is not set with a scheduling priority, and its scheduling priority can be the lowest among all detection modules, and a token bucket is used to control the amount of data written.

[0120] Next, in combination with Figures 6a-6d , the scheduling examples of the dynamic weighted scheduling model, the pipeline model, and the fully parallel model corresponding to this embodiment in the related technology are shown to further distinguish the scheduling processes and effects between this embodiment and the related technology. The illustrated example assumes that the running duration ratios of each detection module are 1:1:2.5:1, 5 threads are allocated, and the scheduling processes of different models for processing the same number of messages (data to be processed) are shown. Among them, a, b, c, and d respectively represent the preliminary inspection module, the secondary confirmation module, the data collection module, and the data processing module, and the thickness of the frames of a, b, c, and d respectively represents the corresponding 5 threads.

[0121] Among them, Figure 6a , Figure 6b and Figure 6c respectively show the optimal scheduling processes of the dynamic weighted scheduling model for processing 21 messages under the same 5 - thread resources, the pipeline model, and the fully parallel model. The dynamic weighted scheduling model only needs 25.5T to process 21 messages, the pipeline model needs 30.5T, and the fully parallel model needs 27.5T.

[0122] From Figure 6a , Figure 6b and Figure 6c 's examples, it can be seen that the dynamic weighted scheduling model and the fully parallel model are superior to the pipeline model. The performance of the dynamic weighted scheduling model and the fully parallel model alternately leads, and can be understood as being basically equivalent.

[0123] Figure 6d shows the scheduling process of the dynamic weighted scheduling model for processing 26 messages under the same 5 - thread resources, which requires a total of 31T. Compared with Figure 6aThe dynamic weighted scheduling model handles 21 message scheduling processes, clearly demonstrating a pipeline-like scheduling approach. Five messages are completed every 5.5 cycles, and the modules executing between messages are staggered, significantly reducing the probability of serial waiting for the same module to access mutually exclusive resources.

[0124] The advantage of the pipelined model over the fully parallel model lies primarily in its performance when scheduling involves accessing mutex resources. The pipelined model staggers the tasks executed by each thread, significantly reducing wasted time spent waiting for mutex resources. Threads can consistently work efficiently without prolonged blocking. However, the pipelined model cannot dynamically adjust thread allocation when module efficiency changes or when initial assessments of module efficiency are inaccurate, thus failing to achieve optimal pipelined performance.

[0125] The dynamic weighted scheduling model, based on the pipeline model, first obtains the upper limit of the scheduling weight corresponding to thread resources, and periodically collects the running status of each module to adjust the thread resource allocation in a timely manner to meet the optimal pipeline ratio. When the optimal pipeline ratio cannot be fully met, resources are prioritized to the stage module closest to message completion (i.e., data processing module > data collection module > secondary confirmation module > initial inspection module) to prevent message backlog, ensure the overall message processing performance, and reduce the processing latency of individual messages.

[0126] As can be seen from the above examples, the dynamic weighted scheduling model corresponding to this embodiment is significantly better than the pipeline model and fully parallel model in related technologies.

[0127] Please refer to Figure 7 , Figure 7 This is a schematic diagram of the structure of a resource scheduling device for a vehicle-mounted intrusion detection system provided in an embodiment of this application. The vehicle-mounted intrusion detection system includes several detection modules for performing different vehicle-mounted intrusion detection stages. The vehicle-mounted intrusion detection stages include an initial detection stage and a post-processing stage, such as... Figure 7 As shown, the device includes:

[0128] The acquisition module 71 is configured to acquire the thread resources required by several detection modules for intrusion detection and the upper limit of the scheduling weight of each of the several detection modules regarding thread resources;

[0129] The first determining module 72 is configured to determine the number of allocable threads in real time based on the sum of thread resources and the current number of threads of one or more detection modules in the post-processing stage when there is data to be processed in one or more detection modules in the post-processing stage.

[0130] The second determining module 73 is configured to determine the allocation weight of each detection module based on the current number of threads of each of the several detection modules and their corresponding scheduling weight upper limit according to the number of allocable threads.

[0131] The allocation module 74 is configured to allocate a corresponding number of threads to each detection module based on the allocation weight. The number of threads is used to process the data to be processed by the corresponding detection module for intrusion detection.

[0132] In one implementation, the detection module in the initial detection phase includes a preliminary detection module for collecting behavioral data; the detection module in the post-processing phase includes a secondary confirmation module for identifying whether the behavior corresponding to the behavioral data is an intrusion behavior, a data collection module for acquiring intrusion data of the intrusion behavior, and a data processing module for generating an intrusion response strategy based on the intrusion data.

[0133] In one embodiment, the vehicle-mounted intrusion detection system further includes several cache queues that are respectively connected to each detection module in the post-processing stage, and the several cache queues are respectively used to store the data to be processed in the corresponding detection module.

[0134] In one implementation, the acquisition module 71 includes:

[0135] The first acquisition unit is configured to acquire the scheduling weight ratio of thread resources among the detection modules based on the runtime of each of the detection modules.

[0136] The second acquisition unit is configured to acquire the thread resources required for intrusion detection by several detection modules and the upper limit of the scheduling weight of each detection module regarding thread resources, based on the scheduling weight ratio.

[0137] In one implementation, the second determining module 73 includes:

[0138] The judgment unit is configured to determine whether the current number of threads of each detection module has reached the number of threads corresponding to the scheduling weight limit based on the current number of threads of each detection module and the corresponding scheduling weight limit.

[0139] The weight determination unit is configured to set the assigned weight of the detection module to zero if the current number of threads of the detection module reaches the number of threads corresponding to the upper limit of the scheduling weight.

[0140] In one implementation, the scheduling weight of the detection module in the initial detection phase has an upper limit of infinity.

[0141] The thread allocation module 74 is also configured to directly allocate the corresponding number of threads to the detection modules in the initial detection stage based on thread resources when there is no data to be processed in all detection modules in the post-processing stage and the sum of the current thread counts of all detection modules is zero.

[0142] In one embodiment, the apparatus further includes:

[0143] The priority determination module determines the priority of several cache queues based on the processing order of the data to be processed by each detection module in the post-processing stage, wherein the processing order is determined based on the data flow between each detection module in the post-processing stage; and determines the scheduling priority of several detection modules based on the priority of several cache queues.

[0144] The allocation module 74 is specifically configured to allocate the corresponding number of threads to each detection module based on the scheduling priority and allocation weight of several detection modules.

[0145] In one embodiment, the apparatus further includes:

[0146] The data control module is configured to control the amount of data to be processed by the detection module in the initial detection phase based on the command bar control algorithm when allocating the corresponding number of threads to the detection module in the initial detection phase.

[0147] Compared to existing vehicle-mounted intrusion detection systems that primarily copy or tailor traditional computer industry intrusion detection systems for vehicles without differentiating the impact of various intrusion behaviors on the vehicle system or providing differentiated optimization, which often leads to system crashes during intrusion flood attacks, this application's embodiment is based on dynamic weighted scheduling. It modularizes intrusion detection, allocates resources through a dynamic weighted algorithm to improve overall detection performance, and controls intrusion detection resource consumption through a token bucket algorithm to achieve a balance between resource consumption and detection performance. Even when facing intrusion flood attacks, it can still perform effective detection.

[0148] For relevant instructions, please refer to the corresponding text. Figures 2-5 The relevant descriptions and effects of the steps in the corresponding embodiments are understood, and will not be elaborated on here.

[0149] Please refer to Figure 8 , Figure 8 A schematic diagram of the electronic device provided in the embodiments of this application, such as... Figure 8 As shown, the electronic device 8 provided in this embodiment includes: a processor 81, and a memory 82 communicatively connected to the processor 81.

[0150] Among them, memory 82 stores computer-executed instructions;

[0151] The computer execution instructions stored in memory 82 are processed by 81 to implement the present application. Figures 2-5 The resource scheduling method for the vehicle intrusion detection system provided in any of the corresponding embodiments.

[0152] The memory 82 and the processor 81 are connected via a bus 83.

[0153] For relevant instructions, please refer to the corresponding text. Figures 2-5 The relevant descriptions and effects of the steps in the corresponding embodiments are understood, and will not be elaborated on here.

[0154] This application also provides a computer-readable storage medium having a computer program stored thereon, the computer program being executed by a processor to implement this application. Figures 2-5 The resource scheduling method for the vehicle intrusion detection system provided in any of the corresponding embodiments.

[0155] The computer-readable storage medium may be ROM, random access memory (RAM), CD-ROM, magnetic tape, floppy disk, and optical data storage device, etc.

[0156] One embodiment of this application provides a computer program product, including a computer program that, when executed by a processor, implements this application. Figures 2-5 The resource scheduling method for the vehicle intrusion detection system provided in any of the corresponding embodiments.

[0157] Figure 9 This is a block diagram illustrating an exemplary embodiment of the present application of a terminal device 900, which may be a mobile phone, computer, digital broadcasting terminal, messaging device, game console, tablet device, medical device, fitness device, personal digital assistant, etc.

[0158] The terminal device 900 may include one or more of the following components: processing component 902, memory 904, power supply component 906, multimedia component 908, audio component 910, input / output (I / O) interface 912, sensor component 914, and communication component 916.

[0159] Processing component 902 typically controls the overall operation of terminal device 900, such as operations associated with display, telephone calls, data communication, camera operation, and recording. Processing component 902 may include one or more processors 920 to execute instructions to complete all or part of the steps of the methods described above. Furthermore, processing component 902 may include one or more modules to facilitate interaction between processing component 902 and other components. For example, processing component 902 may include a multimedia module to facilitate interaction between multimedia component 908 and processing component 902.

[0160] Memory 904 is configured to store various types of data to support the operation of terminal device 900. Examples of this data include instructions for any application or method operating on terminal device 900, contact data, phonebook data, messages, pictures, videos, etc. Memory 904 can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk.

[0161] Power supply component 906 provides power to various components of terminal device 900. Power supply component 906 may include a power management system, one or more power supplies, and other components associated with generating, managing, and distributing power to terminal device 900.

[0162] Multimedia component 908 includes a screen that provides an output interface between terminal device 900 and user. In some embodiments, the screen may include a liquid crystal display (LCD) and a touch panel (TP). If the screen includes a touch panel, the screen may be implemented as a touchscreen to receive input signals from the user. The touch panel includes one or more touch sensors to sense touches, swipes, and gestures on the touch panel. The touch sensors may sense not only the boundaries of touch or swipe actions but also the duration and pressure associated with the touch or swipe operation. In some embodiments, multimedia component 908 includes a front-facing camera and / or a rear-facing camera. When terminal device 900 is in an operating mode, such as shooting mode or video mode, the front-facing camera and / or rear-facing camera may receive external multimedia data. Each front-facing camera and rear-facing camera may be a fixed optical lens system or have focal length and optical zoom capabilities.

[0163] Audio component 910 is configured to output and / or input audio signals. For example, audio component 910 includes a microphone (MIC) configured to receive external audio signals when terminal device 900 is in an operating mode, such as call mode, recording mode, and voice recognition mode. The received audio signals may be further stored in memory 904 or transmitted via communication component 916. In some embodiments, audio component 910 also includes a speaker for outputting audio signals.

[0164] I / O interface 912 provides an interface between processing component 902 and peripheral interface modules, such as keyboards, click wheels, buttons, etc. These buttons may include, but are not limited to, home buttons, volume buttons, power buttons, and lock buttons.

[0165] Sensor assembly 914 includes one or more sensors for providing status assessments of various aspects of terminal device 900. For example, sensor assembly 914 can detect the on / off state of terminal device 900, the relative positioning of components such as the display and keypad of terminal device 900, changes in position of terminal device 900 or a component of terminal device 900, the presence or absence of user contact with terminal device 900, orientation or acceleration / deceleration of terminal device 900, and temperature changes of terminal device 900. Sensor assembly 914 may include a proximity sensor configured to detect the presence of nearby objects without any physical contact. Sensor assembly 914 may also include a light sensor, such as a CMOS or CCD image sensor, for use in imaging applications. In some embodiments, sensor assembly 914 may also include an accelerometer, gyroscope, magnetometer, pressure sensor, or temperature sensor.

[0166] Communication component 916 is configured to facilitate wired or wireless communication between terminal device 900 and other devices. Terminal device 900 can access wireless networks based on communication standards, such as WiFi, 3G, 4G, 5G, or other standard communication networks, or combinations thereof. In one exemplary embodiment, communication component 916 receives broadcast signals or broadcast-related information from an external broadcast management system via a broadcast channel. In one exemplary embodiment, communication component 916 also includes a near-field communication (NFC) module to facilitate short-range communication. For example, the NFC module may be implemented based on radio frequency identification (RFID) technology, Infrared Data Association (IrDA) technology, ultra-wideband (UWB) technology, Bluetooth (BT) technology, and other technologies.

[0167] In an exemplary embodiment, the terminal device 900 may be implemented by one or more application-specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field-programmable gate arrays (FPGAs), controllers, microcontrollers, microprocessors, or other electronic components to perform the functions described in this application. Figures 2-5 The method provided in any of the corresponding embodiments.

[0168] In an exemplary embodiment, a non-transitory computer-readable storage medium including instructions is also provided, such as a memory 904 including instructions, which can be executed by a processor 920 of a terminal device 900 to perform the above-described method. For example, the non-transitory computer-readable storage medium may be a ROM, random access memory (RAM), CD-ROM, magnetic tape, floppy disk, and optical data storage device, etc.

[0169] This application also provides a non-transitory computer-readable storage medium, which, when the instructions in the storage medium are executed by the processor of a terminal device, enables the terminal device 900 to perform the above-described embodiments of this application. Figures 2-5 The method provided in any of the corresponding embodiments.

[0170] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of modules is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple modules or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or modules may be electrical, mechanical, or other forms.

[0171] Other embodiments of this application will readily occur to those skilled in the art upon consideration of the specification and practice of the application disclosed herein. This application is intended to cover any variations, uses, or adaptations of this application that follow the general principles of this application and include common knowledge or customary techniques in the art not disclosed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of this application are indicated by the following claims.

[0172] It should be understood that this application is not limited to the precise structure described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this application is limited only by the appended claims.

Claims

1. A resource scheduling method for a vehicle-mounted intrusion detection system, characterized in that, The vehicle-mounted intrusion detection system includes several detection modules for performing different vehicle-mounted intrusion detection stages, wherein the vehicle-mounted intrusion detection stages include an initial detection stage and a post-processing stage, and the method includes: Based on the runtime of each of the detection modules, the scheduling weight ratio of thread resources among the detection modules is obtained; based on the scheduling weight ratio, the thread resources required by the detection modules for intrusion detection and the upper limit of the scheduling weight of each detection module regarding thread resources are obtained; wherein, the upper limit of the scheduling weight of the detection modules in the initial detection stage is infinite, and the upper limit of the scheduling weight of each detection module in the post-processing stage is the corresponding weight ratio in the scheduling weight ratio plus 1 and rounded up. When there is data to be processed in one or more detection modules in the post-processing stage, the number of available threads is determined in real time based on the sum of the thread resources and the current thread count of one or more detection modules in the post-processing stage. The allocation weight of each detection module is determined based on its current thread count and corresponding scheduling weight limit, according to the number of allocable threads. In the case where the current thread count of a detection module reaches the thread count corresponding to the scheduling weight limit, the allocation weight of that detection module is set to zero. The allocation weight corresponds to the proportion of the number of allocated threads. Based on the allocation weight, a corresponding number of threads are allocated to each detection module. The number of threads is used to process the data to be processed by the corresponding detection module for intrusion detection.

2. The method according to claim 1, characterized in that, The detection module in the initial detection phase includes a preliminary detection module for collecting behavioral data; the detection module in the post-processing phase includes a secondary confirmation module for identifying whether the behavior corresponding to the behavioral data is an intrusion behavior, a data collection module for acquiring intrusion data of the intrusion behavior, and a data processing module for generating an intrusion response strategy based on the intrusion data.

3. The method according to claim 1 or 2, characterized in that, The vehicle-mounted intrusion detection system also includes several cache queues that are respectively connected to each detection module in the post-processing stage. The several cache queues are respectively used to store the data to be processed in the corresponding detection module.

4. The method according to claim 1, characterized in that, After obtaining the thread resources required for intrusion detection by the plurality of detection modules and the upper limit of the scheduling weight of each of the plurality of detection modules with respect to thread resources, the method further includes: When all detection modules in the post-processing stage have no data to be processed and the sum of the current thread counts of all detection modules is zero, the corresponding number of threads is directly allocated to the detection modules in the initial detection stage based on the thread resources.

5. The method according to claim 3, characterized in that, Before allocating the corresponding number of threads to each detection module based on the allocation weight, the process also includes: The priority of the plurality of cache queues is determined based on the processing order of the data to be processed by each detection module in the post-processing stage, wherein the processing order is determined based on the data flow direction between each detection module in the post-processing stage. The scheduling priority of the detection modules is determined based on the priority of the cache queues. The step of allocating a corresponding number of threads to each detection module based on the allocation weight includes: allocating a corresponding number of threads to each detection module based on the scheduling priority of the plurality of detection modules and the allocation weight.

6. The method according to claim 1, characterized in that, Also includes: When allocating the corresponding number of threads to the detection module in the initial detection phase, the number of data to be processed by the detection module in the initial detection phase is controlled based on the command bucket control algorithm.

7. A resource scheduling device for a vehicle-mounted intrusion detection system, characterized in that, The vehicle-mounted intrusion detection system includes several detection modules for performing different vehicle-mounted intrusion detection stages, which include an initial detection stage and a post-processing stage. The device includes: The acquisition module is configured to acquire the scheduling weight ratio of thread resources among the detection modules based on the runtime of each of the detection modules; and acquire the thread resources required for intrusion detection by the detection modules and the upper limit of the scheduling weight of each detection module regarding thread resources based on the scheduling weight ratio; wherein, the upper limit of the scheduling weight of the detection modules in the initial detection stage is infinite, and the upper limit of the scheduling weight of each detection module in the post-processing stage is the corresponding weight ratio in the scheduling weight ratio plus 1 and rounded up; The first determining module is configured to determine the number of allocable threads in real time based on the sum of the thread resources and the current thread count of the one or more detection modules in the post-processing stage when there is data to be processed in one or more detection modules in the post-processing stage. The second determining module is configured to determine the allocation weight of each detection module based on the current number of threads of each of the plurality of detection modules and their corresponding scheduling weight upper limit according to the number of allocable threads. In the case where the current number of threads of a detection module reaches the number of threads corresponding to the scheduling weight upper limit, the allocation weight of the detection module is determined to be zero. The allocation weight corresponds to the proportion of the number of allocated threads. The allocation module is configured to allocate a corresponding number of threads to each detection module based on the allocation weight. The number of threads is used to process the data to be processed by the corresponding detection module for intrusion detection.

8. An electronic device, comprising: A processor, and a memory communicatively connected to the processor; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory to implement the resource scheduling method of the vehicle intrusion detection system as described in any one of claims 1 to 6.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, are used to implement the resource scheduling method of the vehicle intrusion detection system as described in any one of claims 1 to 6.

Images