Blacklist generation method and apparatus, electronic device, and storage medium

Abstract

The present disclosure provides a blacklist generation method and device, electronic equipment and storage medium, relates to the technical field of computers, and particularly relates to the technical field of artificial intelligence such as automatic driving, data processing and simulation testing. The specific implementation scheme is: in response to a simulation task initiation request, the current target blacklist is called; machines in the cluster located in the target blacklist are shielded; the simulation task is submitted to the cluster, and running result data of the simulation task is obtained; the running result data is mined to obtain a fault machine that has a problem in the simulation task; and the target blacklist is updated based on the fault machine. According to the scheme of the present disclosure, the blacklist can be automatically generated in resource scheduling, and then the machines in the current latest target blacklist can be shielded for next time resource scheduling, so that the stability and efficiency of the simulation task running are improved.

Description

Technical Field

[0001] This disclosure relates to the field of computer technology, and in particular to the fields of artificial intelligence technology such as autonomous driving, data processing, and simulation testing. Background Technology

[0002] In the operation of autonomous driving simulation clusters, each simulation batch computing task is scheduled to multiple different clusters, which are resource pools composed of hundreds or thousands of physical machines. Some machines in these clusters may be in a "falsely active" state, showing no abnormalities at the monitoring level. However, actual tasks running on these machines will encounter two problems. One is that the machine environment is unstable, leading to a very high failure rate for business data; the other is that the machine's performance is significantly lower than other normal machines, affecting the efficiency of simulation task execution. The frequent occurrence of such machines in the cluster results in varying degrees of degradation in the stability and performance of business computing. Summary of the Invention

[0003] This disclosure provides a blacklist generation method, apparatus, electronic device, and storage medium.

[0004] According to a first aspect of this disclosure, a method for generating a blacklist is provided, comprising:

[0005] In response to a simulation task initiation request, retrieve the current target blacklist;

[0006] Block machines in the cluster that are on the target blacklist;

[0007] Submit simulation tasks to the cluster and obtain the simulation task execution results data;

[0008] By mining the execution result data, the faulty machines that caused problems in the simulation task can be identified;

[0009] Update the target blacklist based on the faulty machine.

[0010] According to a second aspect of this disclosure, a blacklist generation apparatus is provided, comprising:

[0011] The pull module is used to retrieve the current target blacklist in response to a simulation task request;

[0012] The blocking module is used to block machines in the cluster that are on the target blacklist.

[0013] The first acquisition module is used to submit simulation tasks to the cluster and obtain the running result data of the simulation tasks;

[0014] The mining module is used to mine the running result data to identify the faulty machines that caused problems in the simulation task;

[0015] The first update module is used to update the target blacklist based on faulty machines.

[0016] According to a third aspect of this disclosure, an electronic device is provided, comprising:

[0017] At least one processor; and

[0018] The memory is communicatively connected to the at least one processor; wherein,

[0019] The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform the methods of any embodiment of the present disclosure.

[0020] According to a fourth aspect of this disclosure, a non-transitory computer-readable storage medium is provided storing computer instructions, wherein the computer instructions are configured to cause the computer to perform a method according to any embodiment of this disclosure.

[0021] According to a fifth aspect of this disclosure, a computer program product is provided, including a computer program that, when executed by a processor, implements a method according to any embodiment of this disclosure.

[0022] According to the scheme disclosed herein, a blacklist can be automatically generated during resource scheduling, which can then be used to block machines in the latest target blacklist during the next resource scheduling, thereby improving the stability and efficiency of simulation task execution.

[0023] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of this disclosure, nor is it intended to limit the scope of this disclosure. Other features of this disclosure will become readily apparent from the following description. Attached Figure Description

[0024] In the accompanying drawings, unless otherwise specified, the same reference numerals throughout the various drawings denote the same or similar parts or elements. These drawings are not necessarily drawn to scale. It should be understood that these drawings depict only some embodiments disclosed in this application and should not be construed as limiting the scope of this application.

[0025] Figure 1 This is a flowchart illustrating a blacklist generation method according to an embodiment of the present disclosure;

[0026] Figure 2 This is a schematic diagram of the overall process for automatically generating a blacklist according to embodiments of this disclosure;

[0027] Figure 3 This is a schematic diagram of a blacklist generation mechanism according to an embodiment of the present disclosure;

[0028] Figure 4 This is a schematic diagram of the blacklist activation mechanism according to an embodiment of this disclosure;

[0029] Figure 5 This is a schematic diagram of excavating a faulty machine according to excavation rules based on an embodiment of this disclosure. Figure 1 ;

[0030] Figure 6 This is a schematic diagram of excavating a faulty machine according to excavation rules based on an embodiment of this disclosure. Figure 2 ;

[0031] Figure 7 This is a schematic diagram of excavating a faulty machine according to excavation rules based on an embodiment of this disclosure. Figure 3 ;

[0032] Figure 8 This is a schematic diagram of the structure of a blacklist generation device according to an embodiment of the present disclosure;

[0033] Figure 9 This is a schematic diagram of a scenario based on the blacklist generation method according to an embodiment of this disclosure;

[0034] Figure 10 This is a schematic diagram of the structure of an electronic device used to implement the blacklist generation method of the present disclosure embodiments. Detailed Implementation

[0035] The exemplary embodiments of this disclosure are described below with reference to the accompanying drawings, including various details of the embodiments to aid understanding, and should be considered merely exemplary. Therefore, those skilled in the art will recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope of this disclosure. Similarly, for clarity and brevity, descriptions of well-known functions and structures are omitted in the following description.

[0036] The terms "first," "second," and "third," etc., used in the embodiments, claims, and accompanying drawings of this disclosure are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion, such as including a series of steps or units. A method, system, product, or apparatus is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to these processes, methods, products, or apparatuses.

[0037] In related technologies, autonomous driving simulation requires manual analysis to proactively identify abnormal machines and then manually block them when tasks are submitted to the cluster. The inability to promptly identify and blacklist faulty machines reduces cluster resource availability. Furthermore, blacklisted machines are difficult to remove from the blacklist promptly after maintenance personnel restore them, preventing timely utilization of those resources. Since the repair time for cluster faulty machines is unpredictable and the occurrence of abnormal machines is somewhat sporadic, manually adjusting the blacklisting process after each faulty machine is discovered and manually removing it after it recovers is inflexible, incurs additional manpower costs, and causes significant inconvenience.

[0038] To at least partially address one or more of the aforementioned problems and other potential issues, this disclosure proposes a blacklist generation method that can automatically generate a blacklist during cluster resource scheduling and block abnormal machines based on the blacklist. Specifically, by analyzing the results of autonomous vehicle simulation tasks, the Internet Protocol (IP) addresses of machines in different clusters with unstable environments or degraded performance are identified and added to the cluster machine blacklist upon task submission. Blocking abnormal machines based on the blacklist improves the stability and efficiency of simulation task execution.

[0039] This disclosure provides a method for generating a blacklist. Figure 1 This is a flowchart illustrating a blacklist generation method according to an embodiment of the present disclosure. This blacklist generation method can be applied to a blacklist generation device. The blacklist generation device is located in an electronic device. The electronic device can be physically connected to a cluster or connected to a network. The electronic device includes, but is not limited to, fixed devices and / or mobile devices. For example, fixed devices include, but are not limited to, servers, which can be cloud servers or ordinary servers. For example, mobile devices include, but are not limited to, mobile phones, tablets, and vehicle terminals. In some possible implementations, the blacklist generation method can also be implemented by a processor calling computer-readable instructions stored in memory. Figure 1 As shown, the blacklist generation method includes:

[0040] S101: In response to the simulation task initiation request, retrieve the target blacklist;

[0041] S102: Block the machines in the cluster that are on the target blacklist;

[0042] S103: Submit a simulation task to the cluster and obtain the simulation task's execution result data;

[0043] S104: Mine the data from the running results to identify the faulty machines that caused problems in the simulation task;

[0044] S105: Update the target blacklist based on the faulty machine.

[0045] In this embodiment, the simulation user submits the j-th round of simulation task, where j is an integer not less than 1. In response to the request to initiate the j-th round of simulation task, the server retrieves the target blacklist from the database, obtains the machine IPs in the target blacklist, blocks the machines in the cluster that appear in the target blacklist, and then submits the j-th round of simulation task to the cluster. After the cluster completes the j-th round of simulation task, the server obtains the running result data of the j-th round of simulation task, mines this running result data to identify the faulty machines that caused problems in the j-th round of simulation task, and updates the target blacklist based on the faulty machines so that when the simulation user submits the (j+1)-th round of simulation task, the server can obtain the latest target blacklist in a timely manner.

[0046] In this embodiment of the disclosure, the simulation task initiation request can be initiated manually by the simulation user or automatically triggered by the simulation task. For example, the simulation user can manually initiate the task. Another example is that the server triggers the simulation task periodically and initiates the request. Yet another example is that the simulation task is triggered non-periodicly and the request is initiated. The above are merely illustrative examples and are not intended to limit the method of sending the simulation task initiation request; they are simply not exhaustive.

[0047] In this embodiment, the target blacklist is a list of faulty machines in the cluster, and this target blacklist is dynamically changing; that is, a mining task is triggered periodically by a mining program, and the target blacklist is continuously updated based on the faulty machines obtained in each round of mining. The fields stored in the target blacklist may include:

[0048] (1) Machine IP: The IP address of the machine;

[0049] (2) Version: Update the version, represented by a timestamp. Each update is based on the latest version and can retain all historical bolded data.

[0050] (3) Mining time: The time it takes to obtain the result of the j-th mining based on the mining rules;

[0051] (4) Rule: Mining rule number, that is, which rule was used to mine the j-th mining result record;

[0052] (5) Estimated Time of Arrival (ETA): also known as the expiration time. If the ETA is less than or equal to the current time, it means that the j-th record has expired and is no longer valid; if the ETA is greater than the current time, it means that the machine IP needs to be added to the blacklist and blocked.

[0053] (6) Start time: Extract the start time of the time range from the execution result data;

[0054] (7) End time: The end time of the time range extracted from the running results data.

[0055] It is understandable that the fields stored in the target blacklist can be updated as needed, with new fields added or some existing fields removed.

[0056] In this embodiment of the disclosure, the execution result data is the result data of the j-th round of simulation. For example, the execution result data includes the IP address of the machine running the j-th round of simulation. Another example is that the execution result data includes the error codes generated by the machine during the execution of the j-th round of simulation. Yet another example is that the execution result data includes the execution parameters corresponding to each machine during the execution of the j-th round of simulation. The above are merely illustrative examples and are not intended to limit the content of the execution result data; they are simply not exhaustive.

[0057] In this embodiment of the disclosure, mining the execution result data includes mining the execution result data based on mining conditions. For example, mining can be performed based on the machine type or whether the running computing task is a Central Processing Unit (CPU) task or a Graphics Processing Unit (GPU) task. Another example is that different machine failures may lead to different final execution results; that is, mining can be performed based on the frequency of different types of error codes. Yet another example is to statistically analyze the task execution failure rate at the machine IP level; that is, to statistically analyze the number of task execution errors at the machine level. The above are merely illustrative examples and are not intended to limit the content of the mining rules; they are simply not exhaustive.

[0058] In this embodiment of the disclosure, the machines in the target blacklist are inactive or faulty machines. Inactive machines are those that show no abnormalities at the monitoring level, but exhibit abnormalities during actual task execution. Specifically, the simulation task fails due to machine instability; or the simulation runs less efficiently due to a significant performance drop compared to other normal machines. Faulty machines are damaged machines. For example, simulation tasks fail due to outdated or damaged components, including disks, graphics cards, and CPUs. Another example is a full disk, causing simulation task failure. The above are merely illustrative examples and are not intended to limit the causes of failures for inactive and faulty machines; they are simply not exhaustive.

[0059] In this embodiment of the disclosure, the running result data is mined to identify the faulty machines that caused problems in the simulation task. This includes: mining the running result data based on mining rules to identify the faulty machines that caused problems in the simulation task. The mining rules are formulated according to the machine type and / or the simulation task type.

[0060] In this embodiment, the simulation user submits the j-th round of simulation task. The server responds to the j-th round simulation task initiation request by retrieving the target blacklist from the database, obtaining the machine IPs in the target blacklist, blocking the machines in the target blacklist, submitting the j-th round simulation task, obtaining the running result data of the j-th round simulation task, and performing mining based on mining rule 1 and mining rule 2 respectively. Mining rule 1 involves mining based on the frequency of different types of error codes; mining rule 2 involves counting the number of task running errors at the machine level, and finally obtaining N faulty machines that had problems in the j-th round of simulation task. Based on these N faulty machines, the target blacklist is updated.

[0061] Figure 2 The diagram illustrates the overall process of automatically generating blacklists, as follows: Figure 2 As shown, when a user initiates a simulation task request, the server retrieves a blacklist, blocks the machines on the blacklist, and submits the cluster task. At this point, the cluster resource pool includes normal machines and blocked machines. Normal machines execute the simulation task, while blocked machines are in a stopped task state. After the cluster task ends, the simulation task execution results are generated and stored in the database. The server periodically triggers a mining process, retrieves the simulation task execution results from the database, determines the machines that meet the mining rules, and updates the target blacklist based on these machines.

[0062] The technical solution of this disclosure, in response to a simulation task initiation request, retrieves a target blacklist and blocks machines in the cluster that are on the target blacklist. This eliminates the need for manual blocking of machines on the target blacklist, improving blocking efficiency and thus enhancing simulation efficiency. After blocking machines on the target blacklist, a simulation task is submitted to the cluster, and the simulation task's execution result data is obtained. The execution result data is then analyzed to identify faulty machines that caused problems in the simulation task. Based on these faulty machines, the target blacklist is updated. This achieves automated generation of a machine blacklist during cluster resource scheduling, enabling timely blocking of abnormal machines in the next round of simulation tasks, thereby improving the stability and efficiency of simulation task execution.

[0063] In some embodiments, the blacklist generation method may further include:

[0064] S106: Obtain the release schedule, which includes the estimated release time for each machine;

[0065] S107: In response to detecting that any machine in the target blacklist has reached its expected release time, remove that machine from the target blacklist.

[0066] In this embodiment of the disclosure, the release schedule is the estimated removal time from the blacklist. Each time the mining program is triggered, multiple mining rules are generated based on the machine type and the type of task being performed. When a machine is detected to meet any one of the multiple mining conditions and mining rules, an ETA is configured for that machine, and the target blacklist is updated.

[0067] In this embodiment of the disclosure, in response to detecting that any machine in the target blacklist has reached its expected release time, the server removes that machine from the target blacklist. Machines removed from the blacklist are then released back into the resource pool, awaiting the next round of simulation tasks.

[0068] In this embodiment of the disclosure, the release schedule refers to the time when the machine is removed from the blacklist. The release time varies for each machine and is set according to the cause of the machine's failure. For example, if the cause of the machine's failure is detected as disk damage, repairing the machine requires purchasing a new disk, with an estimated time of 7 days; that is, the machine is blacklisted for 7 days. As another example, if the cause of the machine's failure is detected as a full disk, deleting the data on the disk will allow the machine to operate normally, with an estimated time of 1 day; that is, the machine is blacklisted for 1 day. The above are merely illustrative examples and are not intended to limit the methods for determining the time included in the release schedule; they are simply not exhaustive.

[0069] In this embodiment, the simulation user triggers the submission of the j-th round of simulation tasks. The server responds to the j-th round simulation task initiation request by retrieving a target blacklist from the database, obtaining the machine IPs in the target blacklist, blocking the machines in the target blacklist, submitting the j-th round simulation task, and obtaining the running result data of the j-th round simulation task. Data mining is performed based on mining rule 1 and mining rule 2. Mining rule 1 mines based on the frequency of different types of error codes; mining rule 2 mines based on the number of task running errors at the machine level. Finally, the g-th faulty machine that caused the problem in the j-th round of simulation tasks is obtained. Based on the g-th faulty machine, the target blacklist is updated. The g-th faulty machine triggers an automatic maintenance process. Based on the running error code of the g-th machine, the cause of the g-th machine's failure is obtained. Based on the cause of the failure, the expected release time for the g-th machine is determined to be 2 days.

[0070] Therefore, compared to manually removing faulty machines from the blacklist, setting an estimated release time allows machines that have recovered to normal to be automatically released from the blacklist in a timely manner, saving manpower and improving the running efficiency of simulation tasks.

[0071] In some embodiments, the blacklist generation method may further include:

[0072] S108: Obtain maintenance status data;

[0073] S109: Update the release schedule based on the maintenance status data.

[0074] In this embodiment of the disclosure, the maintenance status refers to the status of machines in the target blacklist. For example, if the g-th machine in the target blacklist triggers the maintenance process, it is in the "waiting for maintenance" status. Another example is if the (g+1)-th machine in the target blacklist triggers the maintenance process, and the maintenance personnel determine that the machine has a damaged disk and needs to purchase a new disk, it is in the "under maintenance" status. Yet another example is if the (g+2)-th machine in the target blacklist triggers the maintenance process, the maintenance personnel repair the j-th machine, and after 2 days the (g+2)-th machine is repaired, it is in the "repaired" status. The above are merely illustrative examples and are not intended to limit the maintenance status to include all states; they are simply not exhaustive examples.

[0075] In this embodiment, the maintenance status data includes all relevant data for the machine under maintenance. For example, during the maintenance of the g-th machine, the maintenance personnel determine the cause of the g-th machine's malfunction based on its operational results. Another example is the maintenance progress of the g-th machine when a maintenance process is triggered. Yet another example is the expected blacklisting time set by the maintenance personnel based on the cause of the machine's malfunction, which is the expected release time for the g-th machine. These are merely illustrative examples and are not intended to limit the scope of all possible data included in the maintenance status data; an exhaustive list is not provided here.

[0076] In this embodiment of the disclosure, the release time refers to the estimated time for each machine in the target blacklist to be added to the blacklist. For example, if the g-th machine in the target blacklist triggers a maintenance process, and the maintenance personnel determine, based on the results, that the graphics card of the g-th machine is damaged, the maintenance time is 2 days, meaning the estimated time for the g-th machine to be added to the blacklist is 2 days. As another example, if the g-th machine in the target blacklist triggers a maintenance process, and the maintenance personnel determine, based on the results, that the operating environment of the g-th machine is unstable, the maintenance time is 1 day, meaning the estimated time for the g-th machine to be added to the blacklist is 1 day. The above are merely illustrative examples and are not intended to limit all possible possibilities for the release time; they are simply not exhaustive.

[0077] The release schedule is a table comprising the estimated addition times to the blacklist for all machines currently included in the target blacklist. This target blacklist is dynamically updated based on the release schedule; that is, when the estimated time for the g-th machine expires, the g-th machine is released into the resource pool and removed from the target blacklist. Furthermore, the release schedule can be generated automatically or adjusted manually.

[0078] Figure 3 The diagram illustrates the blacklist activation mechanism, as shown below. Figure 3 As shown, the simulation user triggers the j-th round of simulation task. In response to the j-th round simulation task request, the server retrieves the target blacklist from the database, obtains the machine IPs in the target blacklist, blocks the machines in the target blacklist, submits the j-th round simulation task, and obtains the execution result data of the j-th round simulation task. Data mining is performed based on mining rule 1 and mining rule 2. Mining rule 1 involves mining based on the frequency of different error codes; machines satisfying mining rule 1 have an ETA of 2 days. Mining rule 2 involves counting the number of task execution errors at the machine level; machines satisfying mining rule 2 have an ETA of 1 day. Finally, the g-th faulty machine that satisfies mining rule 1 in the j-th round of simulation is obtained. The g-th machine obtains its current time, IP address, and ETA, and determines if ETA > Now_time. Since the g-th machine's ETA is greater than the current time (meaning the ETA has not expired), it is expected to be added to the blacklist in 2 days. The g-th machine is then added to the target blacklist and blocked, triggering the machine repair process. After repair, the machine is released from the target blacklist to the resource pool once the ETA expires. In this embodiment, if the g-th machine's ETA is less than or equal to the current time (meaning the ETA has expired), adding the g-th machine to the target blacklist is ineffective, and the g-th machine is removed from the target blacklist.

[0079] In this way, the release schedule can be updated based on maintenance status data; at the same time, the target blacklist can be dynamically updated based on the release schedule, which can automatically and timely release the blocked machines and automatically and timely update the target blacklist, improving the accuracy of blocking machines in the cluster, thereby helping to improve the efficiency of simulation tasks.

[0080] In some embodiments, the blacklist generation method may further include: formulating mining rules based on machine type and / or simulation task type.

[0081] S104 includes: mining the running result data according to the mining rules to obtain the faulty machines that have problems in the simulation task.

[0082] Here, machine type refers to the different types of machines in different clusters. For example, machine type includes CPU machines. Another example is GPU machines. The above are merely illustrative examples and are not intended to limit the inclusion of all possible machine types; they are simply not exhaustive.

[0083] Here, simulation task type refers to the type of task that runs based on the machine type. For example, a CPU task. Or a GPU task. The above are merely illustrative examples and are not intended to limit the number of all possible task types included in the simulation task type; they are simply not exhaustive.

[0084] In this embodiment of the disclosure, mining rules can be formulated according to machine type. When different types of machines fail, the running results may differ; that is, in the j-th round of simulation task, the final running results of the CPU machine and the GPU machine may be different. Therefore, different mining rules need to be formulated for the machine type.

[0085] In this embodiment of the disclosure, mining rules can be formulated according to the type of simulation task. When different machines execute different types of simulation tasks, the error codes of the machines are different; that is, in the j-th round of simulation task, the error codes in the running results of the GPU task and the GPU task are different. Therefore, it is necessary to formulate different mining rules for the type of simulation task.

[0086] In this embodiment of the disclosure, mining rules can be formulated based on machine type and simulation task type. For example, the mining rule for a GPU simulation task corresponding to a CPU machine is denoted as mining rule 1, the mining rule for a CPU simulation task corresponding to a CPU machine is denoted as mining rule 2, the mining rule for a CPU simulation task corresponding to a GPU machine is denoted as mining rule 3, and the mining rule for a GPU simulation task corresponding to a GPU machine is denoted as mining rule 4. Therefore, different mining rules can be formulated based on machine type and simulation task type.

[0087] In this embodiment of the disclosure, the formulation of mining rules may further include: mining based on the frequency of occurrence of different types of error codes, and formulating mining rules; and formulating mining rules based on the failure rate of task execution statistics according to the machine IP dimension. The above is only an illustrative example and is not intended to limit all methods of formulating mining rules; it is simply not an exhaustive list.

[0088] In this embodiment of the disclosure, different ETAs are configured when formulating mining rules. For example, machine a and machine b satisfy mining rule 3, and mining is performed based on the frequency of occurrence of different types of error codes; wherein the error code occurrence frequency of machine a is 10 times, and the error code occurrence frequency of machine b is 26 times, that is, the ETA configured for machine a is less than the ETA configured for machine b. The above is only an illustrative example and is not intended to limit all configuration methods of ETA; it is simply not exhaustive here.

[0089] Figure 4 A schematic diagram illustrating the generation mechanism of the blacklist generation method is shown, such as... Figure 4 As shown, the simulation user submits the j-th round of simulation tasks. The server responds to the request initiated by the j-th round of simulation tasks by retrieving the target blacklist from the database, obtaining the machine IPs in the target blacklist, blocking the machines in the target blacklist, submitting the j-th round of simulation tasks, obtaining the running result data of the j-th round of simulation tasks, and periodically triggering the mining program to trigger mining tasks. Specifically, the mining tasks corresponding to the j-th round of simulation tasks include: mining rule 1, mining rule 2, and mining rule 3. Different ETAs are configured for different mining rules. Data mining is performed according to different mining rules to obtain faulty machines that meet different mining rules, obtaining the IP + mining time + mining rule identifier + ETA of the faulty machine. Based on the information of the faulty machines, the latest version of the target blacklist is generated, and the version number of the target blacklist is represented by a timestamp.

[0090] In this embodiment, the mining task formulated for the j-th round of simulation includes: mining rule 1, mining rule 2, and mining rule 3. The ETA for mining rule 1 is configured as 1 day, the ETA for mining rule 2 as 4 hours, and the ETA for mining rule 3 as 1 month. If the g-th machine is detected to satisfy mining rule 1 and mining rule 2, then the ETA for the g-th machine is 1 day. If the (g+1)-th machine is detected to satisfy mining rule 3, then the ETA for the (g+1)-th machine is 1 month. The above is merely an illustrative example and is not intended to limit the ETA settings for faulty machines; it is simply not exhaustive.

[0091] Therefore, compared to manually blacking out faulty machines and then manually unblocking them after they return to normal, this approach offers greater flexibility and improves the efficiency of simulation tasks.

[0092] In some embodiments, such as Figure 5 As shown, by mining the runtime error codes in the runtime result data, the first type of faulty machine with the target runtime error code is obtained.

[0093] In this embodiment of the disclosure, the target runtime error code can be set or adjusted as needed.

[0094] In this embodiment, the simulation user submits the j-th round of simulation task. The server responds to the j-th round simulation task initiation request by retrieving a target blacklist from the database, obtaining the machine IPs in the target blacklist, blocking the machines in the target blacklist, submitting the j-th round simulation task, and obtaining the execution result data of the j-th round simulation task. The server periodically triggers a mining process, invoking the first mining rule, and performing mining based on the execution error codes in the execution result data; it obtains the first type of faulty machines that meet the target execution error codes, and updates the target blacklist based on the first type of faulty machines.

[0095] In this embodiment, the simulation user submits the j-th round of simulation task. The server responds to the j-th round simulation task initiation request by retrieving a target blacklist from the database, obtaining the machine IPs in the target blacklist, blocking the machines in the target blacklist, submitting the j-th round of simulation task, and obtaining the execution result data of the j-th round simulation task. A mining process is periodically triggered, invoking the first mining rule, and mining is performed based on the execution error codes in the execution result data. If the target execution error code is "000000", then machines that satisfy the target execution error code "000000" are identified as first-type faulty machines, and the target blacklist is updated based on the first-type faulty machines.

[0096] In this way, target error codes can be set to detect the first type of faulty machines, and the target blacklist can be updated based on the first type of faulty machines; the cause of the first type of faulty machine can be accurately obtained, which makes it easier for maintenance personnel to repair the machine, thereby improving the efficiency of the simulation task.

[0097] In some embodiments, such as Figure 6 As shown, based on the number of types of runtime error codes appearing on the same machine in the runtime result data, a second type of faulty machine with a number of types greater than the first threshold is obtained.

[0098] In this embodiment, the simulation user submits the j-th round of simulation task. The server responds to the j-th round simulation task initiation request by retrieving a target blacklist from the database, obtaining the machine IPs in the target blacklist, blocking the machines in the target blacklist, submitting the j-th round simulation task again, and obtaining the execution result data of the j-th round simulation task. A mining process is periodically triggered, invoking a second mining rule. Mining is performed based on the number of types of runtime error codes appearing on the same machine in the execution result data. If the first threshold is 0, then machines that satisfy any type of error code are identified as second-type faulty machines. The target blacklist is updated based on the second-type faulty machines.

[0099] In this embodiment, the simulation user submits the j-th round of simulation task. The server responds to the j-th round simulation task initiation request by retrieving a target blacklist from the database, obtaining the machine IPs in the target blacklist, blocking the machines in the target blacklist, submitting the j-th round simulation task, and obtaining the execution result data of the j-th round simulation task. A mining process is periodically triggered, invoking a second mining rule. Mining is performed based on the number of types of runtime error codes appearing on the same machine in the execution result data. If the first threshold is 2, machines that satisfy three or more types of error codes are identified as second-type faulty machines. The target blacklist is updated based on the second type of faulty machines.

[0100] In this way, the second type of faulty machine can be obtained based on the set error code type, which improves the flexibility of blacklist generation and helps to improve the stability and efficiency of simulation tasks.

[0101] In some embodiments, such as Figure 7 As shown, based on the frequency of the same machine failing to execute a task within a preset time period, a third type of faulty machine with a frequency greater than the second threshold is obtained.

[0102] In this embodiment of the disclosure, the second threshold can be set or adjusted as needed.

[0103] In this embodiment of the disclosure, the preset time period is a pre-defined time period. For example, the preset time period is 1 hour. Another example is 2 days. Yet another example is 1 month. The above are merely illustrative examples and are not intended to limit the range of values ​​for the preset time period; they are simply not exhaustive.

[0104] In this embodiment, the simulation user submits the j-th round of simulation task. The server responds to the j-th round simulation task initiation request by retrieving a target blacklist from the database, obtaining the machine IPs in the target blacklist, blocking the machines in the target blacklist, submitting the j-th round of simulation task, and obtaining the execution result data of the j-th round simulation task. A mining process is triggered periodically, invoking a pre-defined third mining rule, and mining is performed based on the frequency of task failures by the same machine within a preset time period. If the second threshold is 2, then machines that fail to run tasks three or more times in a day will be classified as third-category faulty machines. The target blacklist is updated based on the third-category faulty machines.

[0105] In this way, a third type of faulty machine can be obtained based on the frequency of task failures, which improves the flexibility of blacklist generation and helps to improve the stability and efficiency of simulation tasks.

[0106] In some embodiments, the target blacklist includes a machine identifier. Here, the machine identifier can be represented by a machine IP address. The target blacklist may also include the expected release time corresponding to the machine identifier. The target blacklist may also include at least one of the following: mining time and mining rule identifier.

[0107] In some implementations, the target blacklist can be used to query the mining time, mining rule identifier, and expected release time corresponding to the machine identifier based on the machine identifier.

[0108] Here, the mining rule identifier includes the number of the mining rule.

[0109] For example, in the target blacklist, machine IP = 001, corresponding to the mining time of 8:00 AM on December 17, 2022, with mining rule identification as mining rule 1, and an estimated release time of 2 days; machine IP = 101, corresponding to the mining time of 9:00 AM on December 17, 2022, with mining rule identification as mining rule 2, and an estimated release time of 1 day; machine IP = 109, corresponding to the mining time of 10:00 PM on December 17, 2022, with mining rule identification as mining rule 3, and an estimated release time of 5 days. The above is merely an illustrative example and does not constitute a limitation on all content included in the target blacklist; it is simply not an exhaustive list.

[0110] This allows for the recording of a machine's historical blacklist history, facilitating subsequent monitoring and analysis of faulty machines based on the content recorded in the target blacklist, thereby improving the efficiency of simulation tasks.

[0111] In practical applications, multiple mining rules can be pre-set, and one or more of these rules can be selected to identify faulty machines, thereby updating the target blacklist based on the identified faulty machines.

[0112] It should be understood that Figures 5 to 7 The schematic diagrams shown are merely illustrative and not limiting, and are scalable; those skilled in the art can use them as a basis. Figures 5 to 7 Even with various obvious changes and / or substitutions to the examples, the resulting technical solutions still fall within the scope of this disclosure.

[0113] This disclosure provides a blacklist generation device, such as... Figure 8As shown, the blacklist generation device may include: a retrieval module 801, used to retrieve the target blacklist in response to a simulation task initiation request; a blocking module 802, used to block machines in the cluster that are on the target blacklist; a first acquisition module 803, used to submit a simulation task to the cluster and acquire the simulation task's execution result data; a mining module 804, used to mine the execution result data to obtain the faulty machines that have problems in the simulation task; and a first update module 805, used to update the target blacklist based on the faulty machines.

[0114] In some embodiments, the blacklist generation apparatus includes: a second acquisition module 806. Figure 8 (Not shown in the image), used to obtain the release schedule, which includes the estimated release time for each machine; removal module 807 ( Figure 8 (not shown in the image), used to remove any machine from the target blacklist in response to detecting that any machine in the target blacklist has reached its expected release time.

[0115] In some embodiments, the blacklist generation apparatus may further include: a third acquisition module 808. Figure 8 (Not shown in the image), used to acquire maintenance status data; second update module 809 ( Figure 8 (Not shown in the image) is used to update the release schedule based on maintenance status data.

[0116] In some embodiments, the blacklist generation apparatus may further include: a designation module 810. Figure 8 (Not shown in the image), used to formulate mining rules based on machine type and / or simulation task type; wherein, the mining module 804 is specifically used to mine the running result data according to the mining rules to obtain the faulty machines that have problems in the simulation task.

[0117] In some embodiments, the mining module 804 includes: a first mining submodule, configured to mine based on the runtime error codes in the runtime result data to determine a first type of faulty machine that has a target runtime error code.

[0118] In some embodiments, the mining module 804 may include: a second mining submodule, used to mine based on the number of types of runtime error codes appearing on the same machine in the runtime result data, to obtain a second type of faulty machine with a number of types greater than a first threshold.

[0119] In some embodiments, the mining module 804 may include: a third mining submodule, used to mine based on the frequency of the same machine failing to perform a task within a preset time period, to obtain a third type of faulty machine with a frequency greater than a second threshold.

[0120] In some embodiments, in any of the above blacklist generation devices, the target blacklist includes a machine identifier, and the target blacklist also includes at least one of the following information: the mining time corresponding to the machine identifier, the mining rule identifier, and the expected release time.

[0121] Those skilled in the art should understand that the functions of each processing module in the blacklist generation device of this disclosure embodiment can be understood with reference to the relevant description of the blacklist generation method described above. Each processing module in the blacklist generation device of this disclosure embodiment can be implemented by an analog circuit that implements the functions of this disclosure embodiment, or by running software that executes the functions of this disclosure embodiment on an electronic device.

[0122] The blacklist generation device of this disclosure can automatically generate a blacklist in the resource scheduling of unmanned vehicle clusters, and promptly block abnormal machines in the next round of simulation tasks, thereby helping to improve the stability and efficiency of simulation task operation.

[0123] This disclosure provides a schematic diagram of a blacklist generation scenario, such as... Figure 9 As shown.

[0124] As previously described, the blacklist generation method provided in this disclosure is applied to electronic devices. Electronic devices are intended to represent various forms of digital computers, such as laptops, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframes, and other suitable computers. Electronic devices can also represent various forms of mobile devices, such as personal digital assistants, cellular phones, smartphones, wearable devices, and other similar computing devices.

[0125] In response to a simulation task initiation request, retrieve the target blacklist;

[0126] Block machines in the cluster that are on the target blacklist;

[0127] Submit simulation tasks to the cluster and obtain the simulation task execution results data;

[0128] By mining the execution result data, the faulty machines that caused problems in the simulation task can be identified;

[0129] Update the target blacklist based on the faulty machine.

[0130] The machine data in the target blacklist, as well as the results of the simulation tasks, can be obtained from a data source. The data source can be various forms of data storage devices, such as laptops, desktop computers, workstations, personal digital assistants (PDAs), servers, blade servers, mainframes, and other suitable computers. The data source can also represent various forms of mobile devices, such as PDAs, cellular phones, smartphones, wearable devices, and other similar computing devices. Furthermore, the data source and the user terminal can be the same device.

[0131] It should be understood that Figure 9 The scene diagrams shown are merely illustrative and not restrictive; those skilled in the art can interpret them based on... Figure 9 Even with various obvious changes and / or substitutions to the examples, the resulting technical solutions still fall within the scope of this disclosure.

[0132] The acquisition, storage, and application of user personal information involved in the technical solution disclosed herein comply with the provisions of relevant laws and regulations and do not violate public order and good morals.

[0133] According to embodiments of this disclosure, this disclosure also provides an electronic device, a readable storage medium, and a computer program product.

[0134] Figure 10 A schematic block diagram of an example electronic device 1000 that can be used to implement embodiments of the present disclosure is shown. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device may also represent various forms of mobile devices, such as personal digital assistants, cellular phones, smartphones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the present disclosure described and / or claimed herein.

[0135] like Figure 10As shown, device 1000 includes a computing unit 1001, which can perform various appropriate actions and processes based on a computer program stored in read-only memory (ROM) 1002 or a computer program loaded from storage unit 1008 into random access memory (RAM) 1003. RAM 1003 may also store various programs and data required for the operation of device 1000. The computing unit 1001, ROM 1002, and RAM 1003 are interconnected via bus 1004. Input / output (I / O) interface 1005 is also connected to bus 1004.

[0136] Multiple components in device 1000 are connected to I / O interface 1005, including: input unit 1006, such as keyboard, mouse, etc.; output unit 1007, such as various types of monitors, speakers, etc.; storage unit 1008, such as disk, optical disk, etc.; and communication unit 1009, such as network card, modem, wireless transceiver, etc. Communication unit 1009 allows device 1000 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0137] The computing unit 1001 can be various general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of the computing unit 1001 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various computing units running machine learning model algorithms, digital signal processors (DSPs), and any suitable processor, controller, microcontroller, etc. The computing unit 1001 performs the various methods and processes described above, such as the blacklist generation method. For example, in some embodiments, the blacklist generation method may be implemented as a computer software program tangibly contained in a machine-readable medium, such as storage unit 1008. In some embodiments, part or all of the computer program may be loaded and / or installed on device 1000 via ROM 1002 and / or communication unit 1009. When the computer program is loaded into RAM 1003 and executed by the computing unit 1001, one or more steps of the blacklist generation method described above may be performed. Alternatively, in other embodiments, the computing unit 1001 may be configured to perform a blacklist generation method by any other suitable means (e.g., by means of firmware).

[0138] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-chip (SoCs), complex programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0139] The program code used to implement the methods of this disclosure may be written in any combination of one or more programming languages. This program code may be provided to a processor or controller of a general-purpose computer, special-purpose computer, or other programmable data processing apparatus, such that when executed by the processor or controller, the program code causes the functions / operations specified in the flowcharts and / or block diagrams to be implemented. The program code may be executed entirely on a machine, partially on a machine, as a standalone software package partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0140] In the context of this disclosure, a machine-readable medium can be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium can be, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory, read-only memory, erasable programmable read-only memory (EPROM), flash memory, optical fiber, compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0141] To provide interaction with a user, the systems and techniques described herein can be implemented on a computer having: a display device (e.g., a cathode ray tube (CRT) or liquid crystal display (LCD) monitor) for displaying information to the user; and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the computer. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0142] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as a data server), or computing systems that include middleware components (e.g., an application server), or computing systems that include frontend components (e.g., a user computer with a graphical user interface or web browser through which a user can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., a communication network). Examples of communication networks include local area networks (LANs), wide area networks (WANs), and the Internet.

[0143] Computer systems may include clients and servers. Clients and servers are generally geographically separated and typically interact via communication networks. Client-server relationships are created by computer programs running on the respective computers and having a client-server relationship with each other. Servers may be cloud servers, distributed system servers, or servers incorporating blockchain technology. It should be understood that steps can be rearranged, added, or deleted using the various forms of processes shown above. For example, the steps described in this disclosure may be executed in parallel, sequentially, or in different orders, as long as the desired results of the technical solutions disclosed in this disclosure are achieved, and this is not limited herein.

[0144] The specific embodiments described above do not constitute a limitation on the scope of protection of this disclosure. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the principles of this disclosure should be included within the scope of protection of this disclosure.

Claims

1. A blacklist generation method, applied to an autonomous driving simulation test cluster, comprising: In response to a simulation task initiation request, the current target blacklist is retrieved, wherein the target blacklist includes machine identifier, mining rule identifier, version timestamp, expected release time, mining time, and a time window corresponding to the mining time; the time window includes start time and end time. Block the machines in the cluster that are on the target blacklist; Submit the simulation task to the cluster and obtain the execution result data of the simulation task, which includes machine performance data and execution error codes; By mining the execution result data, the faulty machines that caused problems in the simulation task can be identified; The mining program triggers mining tasks periodically, and updates the target blacklist based on each faulty machine. The update of the target blacklist includes: Iterate through the mining rules corresponding to the faulty machine, set the estimated release time of the faulty machine to the maximum value among the estimated release times corresponding to each mining rule, and dynamically update the estimated release time based on the mining rules and / or maintenance status data; When the estimated release time is greater than the current time, the target blacklist is updated based on the machine identifier, the mining rule identifier, the version timestamp, the mining time, and the time window; When the expected release time is less than or equal to the current time, the faulty machine will be removed from the target blacklist.

2. The method according to claim 1, further comprising: Obtain the release schedule, which includes the estimated release time for each machine; In response to detecting that any machine in the target blacklist has reached its expected release time, the machine is removed from the target blacklist.

3. The method according to claim 2, further comprising: Obtain maintenance status data; The release schedule is updated based on the maintenance status data.

4. The method according to claim 1, further comprising: Develop mining rules based on machine type and / or simulation task type; Among them, mining the execution result data reveals faulty machines that caused problems in the simulation task, including: The running result data is mined according to the mining rules to obtain the faulty machines that have problems in the simulation task.

5. The method according to claim 4, wherein, The step of mining the execution result data according to the mining rules to obtain the faulty machines that caused problems in the simulation task includes: Based on the runtime error codes in the runtime result data, the first type of faulty machine that has the target runtime error code is obtained.

6. The method according to claim 4, wherein, The step of mining the execution result data according to the mining rules to obtain the faulty machines that caused problems in the simulation task includes: Based on the number of types of runtime error codes appearing on the same machine in the runtime result data, a second type of faulty machine with a number of types greater than a first threshold is obtained.

7. The method according to claim 4, wherein, The step of mining the execution result data according to the mining rules to obtain the faulty machines that caused problems in the simulation task includes: Based on the frequency of the same machine failing to execute a task within a preset time period, a third type of faulty machine is identified, whose frequency is greater than a second threshold.

8. A blacklist generation device, applied to an autonomous driving simulation test cluster, comprising: The pull module is used to retrieve the current target blacklist in response to a simulation task initiation request. The target blacklist includes machine identifier, mining rule identifier, version timestamp, expected release time, mining time, and a time window corresponding to the mining time. The time window includes start time and end time. The blocking module is used to block machines in the cluster that are on the target blacklist. The first acquisition module is used to submit the simulation task to the cluster and acquire the running result data of the simulation task, the running result data including machine performance data and running error codes; The mining module is used to mine the running result data to identify the faulty machines that have problems in the simulation task; The first update module is used to trigger a mining task periodically through the mining program, and update the target blacklist based on each of the faulty machines. The first update module includes: The time update submodule is used to traverse the mining rules corresponding to the faulty machine, set the expected release time of the faulty machine to the maximum value among the expected release times corresponding to each mining rule, and dynamically update the expected release time based on the mining rules and / or maintenance status data. A new submodule has been added to the list, which is used to update the target blacklist based on the machine identifier, the mining rule identifier, the version timestamp, the mining time, and the time window when the expected release time is greater than the current time. The list removal submodule is used to remove the faulty machine from the target blacklist when the expected release time is less than or equal to the current time.

9. The apparatus according to claim 8, further comprising: The second acquisition module is used to acquire the release schedule, which includes the expected release time for each machine. A removal module is configured to remove any machine from the target blacklist in response to detecting that any machine in the target blacklist has reached its expected release time.

10. The apparatus according to claim 9, further comprising: The third acquisition module is used to acquire maintenance status data; The second update module is used to update the release schedule based on the maintenance status data.

11. The apparatus according to claim 8, further comprising: A module for defining mining rules based on machine type and / or simulation task type; Specifically, the mining module is used to mine the running result data according to the mining rules to obtain the faulty machines that have problems in the simulation task.

12. The apparatus according to claim 11, wherein, The mining module includes: The first mining submodule is used to mine based on the running error codes in the running result data to obtain the first type of faulty machine that has the target running error code.

13. The apparatus according to claim 11, wherein, The mining module includes: The second mining submodule is used to mine based on the number of types of running error codes that appear on the same machine in the running result data, and to obtain a second type of faulty machine whose number of types is greater than a first threshold.

14. The apparatus according to claim 11, wherein, The mining module includes: The third mining submodule is used to mine based on the frequency of the same machine failing to execute a task within a preset time period, and to obtain a third type of faulty machine whose frequency is greater than a second threshold.

15. An electronic device comprising: At least one processor; as well as A memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform the method of any one of claims 1-7.

16. A non-transitory computer-readable storage medium storing computer instructions, wherein, The computer instructions are used to cause the computer to perform the method according to any one of claims 1-7.

17. A computer program product comprising a computer program that, when executed by a processor, implements the method according to any one of claims 1-7.

Images