A test vehicle detection scheme execution method and system based on resource clustering constraints

Abstract

The application provides a resource clustering constraint-based sample vehicle detection scheme execution method and system, and belongs to the technical field of vehicle sample vehicle inspection. The method comprises the following steps: dividing resource constraint types for each detection task through a resource clustering model; calling a resource scheduling strategy according to the division result, executing a multi-level resource conflict detection and time window allocation algorithm, generating a preliminary detection scheme and pushing the preliminary detection scheme to an execution terminal; after receiving a confirmation instruction, locking the scheme as a formal detection scheme and updating a resource occupation plan in a device account database; and when any execution terminal initiates a scheme adjustment request, generating an adjusted detection scheme based on an incremental rescheduling algorithm. The application can effectively avoid resource allocation conflicts, improve the executability of the sample vehicle detection scheme and the adjustment efficiency.

Description

Technical Field

[0001] This invention belongs to the field of automotive prototype inspection technology, and in particular relates to a prototype inspection scheme execution method and system based on resource clustering constraints. Background Technology

[0002] The statements in this section are merely background information related to the present invention and do not necessarily constitute prior art.

[0003] Vehicle prototype testing typically involves various testing equipment, test samples, and collaboration among multiple departments. Currently, before execution, testing tasks rely primarily on manual resource coordination and plan development. This involves testing personnel manually checking equipment status, communicating equipment usage times, and coordinating sample flow based on their experience, ultimately forming a testing execution plan.

[0004] This detection method has the following technical problems: (1) Delayed identification of resource conflicts leads to infeasibility or frequent changes in testing plans. The resources involved in prototype vehicle testing include fixed equipment (such as emission analysis systems, crash test benches, and other large equipment fixed to specific sites), non-fixed equipment (such as portable data acquisition instruments, mobile sensors, and other equipment that can be moved between different sites), and test samples (prototype vehicles and their components). Different resources have different spatial attributes and temporal availability characteristics, and some testing items will damage the samples (such as crash tests, material sampling tests, etc.), further increasing the time dependence and sequential constraints between resources. Under the existing testing methods, the above-mentioned complex resource constraints are difficult to be fully and in real time incorporated into the overall planning. This often results in the same equipment or sample being repeatedly assigned to different testing tasks, non-fixed equipment failing to arrive at the designated location on time due to insufficient transportation time, and the failure to reasonably coordinate the use of samples for destructive testing and non-destructive testing. As a result, the developed testing plan frequently exposes resource occupation conflicts during actual implementation, requiring repeated adjustments and rework.

[0005] (2) The global impact of adjusting the testing plan is uncontrollable, resulting in low execution efficiency. In the actual testing process, due to factors such as fluctuations in the arrival time of the prototype vehicle, temporary equipment failures, or changes in testing conditions, it is often necessary to adjust the established testing plan. Under the current technology, when the time or resource requirements of a certain testing task change, the scheduler cannot quickly assess the impact of the change on other established testing tasks, and often needs to carry out global manual coordination again, or even overturn the original plan and formulate a new one. Summary of the Invention

[0006] To overcome the shortcomings of the prior art, the present invention provides a prototype vehicle testing scheme execution method and system based on resource clustering constraints, which can effectively avoid resource allocation conflicts and improve the executability and adjustment efficiency of the prototype vehicle testing scheme.

[0007] To achieve the above objectives, one or more embodiments of the present invention provide the following technical solutions: The first aspect of this invention provides a method for implementing a prototype vehicle testing scheme based on resource clustering constraints.

[0008] A prototype vehicle testing scheme execution method based on resource clustering constraints includes: Obtain the set of testing tasks to be executed and build an equipment ledger database; Based on the required equipment identifiers and sample constraint labels corresponding to each detection task in the detection task set, each detection task is automatically assigned to the matching resource constraint type through a resource clustering model. Based on the resource constraint type of the detection task, the corresponding resource scheduling strategy is invoked, and a multi-level resource conflict detection and time window allocation algorithm is executed to generate a preliminary detection plan for each detection task, which is then pushed to at least one execution terminal to await instruction feedback. Upon receiving confirmation from any execution terminal, the preliminary detection plan is locked as the formal detection plan, and the resource usage plan in the equipment ledger database is updated. At the same time, the system continuously receives signals from execution terminals. When any execution terminal initiates a plan adjustment request, the system executes an incremental rescheduling algorithm while maintaining the current resource constraints, generates the adjusted detection plan, and synchronously updates it to all execution terminals.

[0009] Furthermore, the detection task set includes detection item identifiers, required equipment identifiers, and sample constraint labels, wherein the sample constraint labels include destructive labels and non-destructive labels; the equipment status information in the equipment ledger database includes the fixed attributes, current location, and real-time availability status of each device.

[0010] Furthermore, the resource clustering model includes a first judgment unit and a second judgment unit; wherein, the first judgment unit is used to determine whether all the equipment required to complete the corresponding detection task has fixed attributes based on the required equipment identifier, and the second judgment unit is used to determine whether the corresponding detection task is a destructive detection based on the sample constraint label; the resource clustering model executes the following inclusion logic based on the output results of the first judgment unit and the second judgment unit: When it is determined that all required equipment is fixed and the sample is not destroyed, it is classified as the first type; When it is determined that the required equipment is not all fixed and the sample is non-destructive, it is classified as the second type. When it is determined that all required equipment is fixed and the sample is destroyed, it is classified as the third type.

[0011] Furthermore, the resource scheduling strategies implemented for the first type of detection task include: The first resource locking step involves receiving a sample usage time period request sent by the client, wherein the sample usage time period request includes the start time and the estimated duration. The first conflict detection step, based on the equipment ledger database, checks whether the fixed equipment and samples required for the detection task are in an idle state within the time window corresponding to the sample usage period request. In the first allocation step, if the conflict detection is passed, the fixed equipment and sample are locked within the current time window, and this time window is used as the suggested execution time in the preliminary detection plan.

[0012] Furthermore, the resource scheduling strategies implemented for the second type of detection task include: The second resource query step involves obtaining the current location of non-fixed equipment required for the testing task based on the equipment ledger database. The second time calculation step involves obtaining the time window and location occupied by the locked first type of detection task after the first type of detection task completes resource locking; The second allocation step involves automatically calculating and pushing an available idle time window as a suggested execution time based on the current location of the non-fixed device and the location of the first type of detection task. The idle time window is located between two adjacent locked time windows and its duration is not less than the estimated duration of the second type of detection task.

[0013] Furthermore, the resource scheduling strategies implemented for the third type of detection task include: The third waiting step is to wait until both the first and second type of detection tasks have completed resource locking, and then determine the remaining idle time period of the fixed equipment in the equipment ledger database. The third allocation step involves using the remaining idle time period as a candidate execution time window for the third type of detection task, and locking the fixed equipment and the sample to be destroyed for the third type of detection task within the candidate execution time window.

[0014] Furthermore, the implementation of the incremental rescheduling algorithm includes: Receive a scheme adjustment request, which includes the target detection task identifier and the expected new execution time; lock the resource usage plan of other tasks in the current formal detection scheme except for the target detection task; using the new execution time as input, re-execute the resource scheduling strategy corresponding to the resource constraint type of the target detection task only; If rescheduling is successful, an adjusted detection plan is generated, and the resource usage information of the target detection task is updated in the resource usage plan; if rescheduling fails, a rescheduling failure message carrying the reason for the conflict is returned to the execution terminal.

[0015] A second aspect of the present invention provides a prototype vehicle testing scheme execution system based on resource clustering constraints.

[0016] A prototype vehicle testing system based on resource clustering constraints includes: The equipment ledger database is configured to store and maintain equipment status information, which includes the fixed attributes, current location, and real-time availability status of each device. The task acquisition module is configured to acquire a set of detection tasks to be executed, wherein each detection task in the detection task set includes a detection item identifier, a required equipment identifier, and a sample constraint label. The resource clustering module is configured to automatically assign each detection task to a matching resource constraint type based on the required equipment identifier and sample constraint label corresponding to each detection task in the detection task set, using a built-in resource clustering model. The scheduling engine module is configured to: based on the resource constraint type of the detection task, call the corresponding resource scheduling strategy, execute multi-level resource conflict detection and time window allocation algorithms to generate a preliminary detection plan for each detection task; The communication module is configured to: push the preliminary detection scheme to the execution terminal and continuously receive instruction feedback; The resource locking module is configured to: upon receiving a confirmation instruction from any execution terminal, lock the preliminary detection plan as the formal detection plan and update the resource usage plan in the equipment ledger database; The rescheduling module is configured to: simultaneously and continuously receive signals from execution terminals; when any execution terminal initiates a scheme adjustment request, execute an incremental rescheduling algorithm while maintaining the current resource constraints, generate an adjusted detection scheme, and synchronously update it to all execution terminals through the communication module.

[0017] A third aspect of the present invention provides a computer-readable storage medium having a program stored thereon, which, when executed by a processor, implements the steps of the prototype vehicle testing scheme execution method based on resource clustering constraints as described in the first aspect of the present invention.

[0018] The fourth aspect of the present invention provides an electronic device, including a memory, a processor, and a program stored in the memory and executable on the processor, wherein the processor executes the program to implement the steps in the prototype vehicle detection scheme execution method based on resource clustering constraints as described in the first aspect of the present invention.

[0019] The above one or more technical solutions have the following beneficial effects: (1) This invention uses a resource clustering model to automatically classify detection tasks into a first type, a second type, or a third type based on two dimensions: whether the equipment required for the detection task has fixed attributes and whether the sample is a destructive test. Different resource scheduling strategies are then invoked for each type. This mechanism incorporates multi-dimensional resource constraints, such as the spatial exclusivity of fixed equipment, the time constraints of non-fixed equipment, and the sample usage priority between destructive and non-destructive tests, into a unified automated scheduling framework. This fundamentally avoids problems such as the repeated allocation of the same equipment or sample, the inability of non-fixed equipment to arrive in time due to insufficient transportation time, and sample usage conflicts between destructive and non-destructive tests. As a result, the feasibility of the detection scheme is significantly improved, and repeated adjustments and rework caused by resource conflicts are reduced.

[0020] (2) When receiving a scheme adjustment request initiated by the execution terminal, this invention first locks the resource allocation plans of all tasks in the current formal detection scheme except for the target detection task, ensuring that the stability of the existing scheme is not affected. Then, using only the new execution time as input, it re-executes the resource scheduling strategy corresponding to the resource constraint type of the target detection task, rather than overturning the entire scheme for global rescheduling. If the rescheduling is successful, only the resource allocation information of the target detection task is updated in the resource allocation plan; if it fails, a rescheduling failure message carrying the specific conflict reason is returned to the requesting terminal. This incremental adjustment mechanism allows schedulers to quickly know whether a change to a task is feasible and the root cause of the conflict without global manual coordination, and the scope of the adjustment is strictly limited to the target detection task itself, without affecting other locked tasks. As a result, the time and communication costs of adjusting the detection scheme are greatly reduced, and the situation of global rework or execution site shutdown due to a single task change is avoided, significantly improving the detection execution efficiency.

[0021] Advantages of additional aspects of the invention will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of the invention. Attached Figure Description

[0022] The accompanying drawings, which form part of this invention, are used to provide a further understanding of the invention. The illustrative embodiments of the invention and their descriptions are used to explain the invention and do not constitute an improper limitation of the invention.

[0023] Figure 1 This is a flowchart of a prototype vehicle testing scheme execution method based on resource clustering constraints in Embodiment 1 of the present invention.

[0024] Figure 2This is a flowchart illustrating how the corresponding resource scheduling strategy is invoked based on the resource constraint type of the detection task in Embodiment 1 of the present invention.

[0025] Figure 3 This is an architecture diagram of a prototype vehicle testing scheme execution system based on resource clustering constraints in Embodiment 2 of the present invention. Detailed Implementation

[0026] It should be noted that the following detailed descriptions are exemplary and intended to provide further illustration of the invention. Unless otherwise specified, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this invention pertains.

[0027] It should be noted that the terminology used herein is for the purpose of describing particular implementations only and is not intended to limit the exemplary implementations of the present invention.

[0028] Where there is no conflict, the embodiments and features in the embodiments of the present invention can be combined with each other.

[0029] Example 1 This embodiment discloses a prototype vehicle testing scheme execution method based on resource clustering constraints.

[0030] like Figure 1 As shown, a prototype vehicle detection scheme execution method based on resource clustering constraints includes: Step S1: Obtain the set of detection tasks to be executed and build the equipment ledger database; Step S2: Based on the required equipment identifiers and sample constraint labels corresponding to each detection task in the detection task set, each detection task is automatically assigned to the matching resource constraint type through a resource clustering model; Step S3: Based on the resource constraint type of the detection task, call the corresponding resource scheduling strategy, execute the multi-level resource conflict detection and time window allocation algorithm to generate a preliminary detection plan for each detection task, and push it to at least one execution terminal to wait for instruction feedback. Step S4: After receiving confirmation instructions from any execution terminal, lock the preliminary detection plan as the formal detection plan and update the resource usage plan in the equipment ledger database; at the same time, continuously receive signals from execution terminals. When any execution terminal initiates a plan adjustment request, execute the incremental rescheduling algorithm under the condition of maintaining the current resource constraints, generate the adjusted detection plan and update it synchronously to all execution terminals.

[0031] Based on the above process, this invention can effectively avoid resource allocation conflicts and improve the executability and adjustment efficiency of the prototype testing scheme. To facilitate understanding of the technical solution of this invention, the specific implementation methods of this invention will be further explained and described below.

[0032] In step S1, the set of detection tasks to be executed is obtained, and the equipment ledger database is constructed.

[0033] The system receives test task data to be executed from the testing management platform or upstream task publishing system. This data is transmitted in a structured data format (such as JSON or XML). The system parses this data, extracting the test item identifier, required equipment identifier, and sample constraint label for each test task. The test item identifier uniquely indicates the test content to be performed (e.g., emissions testing, impact testing, or material sampling testing); the required equipment identifier is a set of one or more equipment numbers indicating the equipment necessary to complete the test item; the sample constraint label indicates the consuming nature of the sample by the test task, including both destructive and non-destructive labels. All parsed test tasks are then aggregated into a set of test tasks to be executed.

[0034] During system initialization, basic information and real-time status information of all equipment are imported from the equipment management subsystem. The equipment ledger database stores records for each device in the form of relational tables. Each record contains a unique device identifier, fixed attributes, current location, and real-time availability status. The fixed attributes are Boolean fields used to indicate whether the device is a large piece of equipment permanently installed at a specific site (such as an emissions analysis system or a crash test bench). The current location is a text field used to record the device's current location or workstation information. For fixed equipment, this field corresponds to the installation location; for non-fixed equipment, this field is dynamically updated as the equipment moves around. The real-time availability status includes three states: "idle," "occupied," and "under maintenance," and is associated with corresponding occupancy time windows. During system operation, the equipment ledger database continuously receives status update signals from the device itself or manually entered data to maintain data real-time performance.

[0035] In this embodiment, the equipment ledger database is implemented using the relational database MySQL. This database contains a data table as shown in Table 1, which is used to uniquely and deterministically represent each resource entity.

[0036] Table 1. Field names, data types, corresponding value constraints, and meaning definitions of the data table.

[0037] Test samples (prototype vehicles and their components) are stored at the same level as fixed equipment (large, immovable testing facilities installed in specific locations, such as emission analysis systems and crash test benches) and non-fixed equipment (portable testing instruments that can be moved between different locations, such as portable data acquisition devices and mobile sensors). All locking operations of the scheduling engine are converted into atomic update operations on the available_status, occupied_start, and occupied_end fields of this table.

[0038] In step S2, based on the required equipment identifiers and sample constraint labels corresponding to each detection task in the detection task set, a resource clustering model automatically assigns each detection task to a matching resource constraint type. Specifically, for each detection task in the detection task set, its required equipment identifier set and sample constraint label are extracted and used as input parameters for the resource clustering model. The resource clustering model reads the equipment records corresponding to the required equipment identifiers from the equipment ledger database, obtains the fixed attribute values ​​for each piece of equipment, and simultaneously reads the values ​​of the sample constraint labels. It performs classification based on these two types of input features and marks the classification result as the resource constraint type label for that detection task, so that subsequent steps can invoke the corresponding scheduling strategy based on this label.

[0039] The resource clustering model includes a first judgment unit and a second judgment unit. The first judgment unit determines whether all equipment required to complete a corresponding testing task has fixed attributes based on the required equipment identifiers. The second judgment unit determines whether the corresponding testing task is a destructive test based on the sample constraint label. Specifically, the first judgment unit receives a set of required equipment identifiers for a testing task and queries the fixed attribute field corresponding to each equipment identifier in the equipment ledger database. If the fixed attribute of all equipment in the set is "yes," the judgment result is "all fixed"; if the fixed attribute of any equipment in the set is "no," the judgment result is "not all fixed." The second judgment unit reads the sample constraint label carried by the testing task. If the label value is "destructive label," the judgment result is "destructive test"; if the label value is "non-destructive label," the judgment result is "non-destructive test."

[0040] Based on this, the resource clustering model executes the following classification logic according to the outputs of the first and second judgment units: when all required equipment is fixed and the sample is non-destructive, it is classified into the first type; when not all required equipment is fixed and the sample is non-destructive, it is classified into the second type; when all required equipment is fixed and the sample is destructive, it is classified into the third type. Specifically, the resource clustering model has a built-in decision table, which uses the output of the first judgment unit ("all fixed" or "not all fixed") and the output of the second judgment unit ("destructive detection" or "non-destructive detection") as a joint index, mapping to the corresponding resource constraint type identifier. For each detection task, the outputs of the first and second judgment units are input into this decision table for matching. If a match is found in the first type, the resource constraint type of the detection task is marked as "first type"; if a match is found in the second type, it is marked as "second type"; if a match is found in the third type, it is marked as "third type".

[0041] Furthermore, as a deterministic output mapping function, the resource clustering model has its first and second decision units defined as follows: ; ; in, and These represent the output functions of the first and second decision units, respectively. This represents the set of device identifiers required for the detection task, which can be obtained by parsing the required device identifier field of the detection task set. The sample constraint label represents the detection task, and its value is a set of {destructive label, non-destructive label}.

[0042] The final clustering mapping table is logically represented as follows: ; in, This represents a mapping function.

[0043] In step S3, based on the resource constraint type of the detection task, the corresponding resource scheduling strategy is invoked, and a multi-level resource conflict detection and time window allocation algorithm is executed to generate a preliminary detection plan for each detection task. This plan is then pushed to at least one execution terminal to await instruction feedback. The preliminary detection plan includes a suggested execution time, execution location, and required sample range.

[0044] Specifically, for each detection task in the detection task set, based on the resource constraint type marked in step S2, the resource scheduling strategy corresponding to the resource constraint type is invoked from the scheduling engine. In this embodiment, the scheduling engine is implemented using Spring Boot microservices. It has a unique global priority scheduling queue and holds read-write lock permissions on the equipment_inventory database. The scheduling engine sorts all detection tasks according to a preset priority order and processes them sequentially. The first, second, and third types of tasks have a fixed processing priority: all first-type detection tasks are processed first, then all second-type detection tasks, and finally all third-type detection tasks, to ensure the orderly allocation of resources. Each type of task performs specific conflict detection and time window allocation operations according to its corresponding resource scheduling strategy, ultimately generating a preliminary detection plan record for each detection task. After all detection tasks have completed the above processing, all preliminary detection plan records are summarized into a preliminary detection plan set, pushed to at least one execution terminal through a communication interface, and enter a state of waiting for instruction feedback.

[0045] like Figure 2 As shown, when the resource constraint type of the detection task is type 1, the resource scheduling policy for type 1 is invoked: The first resource locking step involves receiving a sample usage time period request from the client. This request includes the start time and estimated duration. Specifically, when the scheduling engine processes a first-type detection task according to global priority, it sends a time request message to the client (such as the detection task initiator or scheduler's terminal), requesting that the desired sample usage start time and estimated duration be specified for the detection task. Upon receiving this request, the client returns a sample usage time period request, which includes the start time (formatted as year-month-day hour:minute:second) and the estimated duration (in minutes).

[0046] The first conflict detection step, based on the equipment ledger database, checks whether the fixed equipment and samples required for the testing task are idle within the time window corresponding to the sample usage time period request. Specifically, the scheduling engine calculates a time window start time based on the start time and estimated duration returned by the client. Then, it queries the equipment ledger database for the real-time availability status of all fixed equipment required for the testing task, as well as the occupancy status of the samples to be tested. If all fixed equipment is "idle" and the sample is not locked by other testing tasks within the time window, the conflict detection is considered successful. If any fixed equipment is "occupied" or "under maintenance" within the time window, or if the sample is locked by other testing tasks, the conflict detection is considered unsuccessful, a conflict indication is returned to the client, and the system waits for a new sample usage time period request.

[0047] In the first allocation step, if the conflict detection passes, the fixed equipment and sample are locked within the current time window, and this time window is used as the suggested execution time in the preliminary testing plan. Specifically, after the conflict detection passes, the scheduling engine immediately updates the status of the corresponding fixed equipment in the equipment ledger database to "occupied" and writes the time window into the equipment's occupancy time window field; simultaneously, the sample to be tested is marked as locked, and the testing task identifier and time window for locking the sample are recorded. Subsequently, this time window is written as the suggested execution time into the preliminary testing plan record for this testing task, and the location of this testing task is determined to be the site where the fixed equipment is located.

[0048] When the resource constraint type of the detection task is type 2, the resource scheduling policy for type 2 is invoked: The second resource query step involves obtaining the current location of the non-fixed equipment required for the inspection task based on the equipment ledger database. Specifically, when processing the second type of inspection task, the scheduling engine first extracts the non-fixed equipment identifiers (i.e., equipment with a fixed attribute of "no") from the set of equipment identifiers required for the inspection task, and then queries the current location field of these non-fixed equipment in the equipment ledger database to obtain the site or workstation information of each non-fixed equipment.

[0049] The second time calculation step involves obtaining the time windows and locations occupied by the locked first-type detection tasks after the first type of detection tasks have completed resource locking. Specifically, after all first-type detection tasks have completed the first allocation step, the scheduling engine reads the occupied time windows and their corresponding location information of all fixed devices locked by the first-type detection tasks from the device ledger database, forming a list of locked time windows arranged in chronological order.

[0050] The second allocation step involves automatically calculating and pushing available idle time windows as suggested execution times based on the current location of the non-fixed device and the location of the first type of detection task. These idle time windows are located between two adjacent locked time windows, and their duration is not less than the estimated duration of the second type of detection task. Specifically, the scheduling engine reads the estimated duration of the currently processed task. Starting from the start time of the first time window in the locked time window list, it sequentially checks the interval between every two adjacent locked time windows and determines whether this interval is not less than the estimated duration of the current second type of detection task. If a matching interval exists, its start time is used as the suggested execution time, and the location of the corresponding first type of detection task is used as the execution location. If no matching interval exists, the suggested execution time is then determined by starting from the end time of the last locked time window after the end of the locked time window list and extending forward to an idle period that can accommodate the estimated duration. After determining the recommended execution time, the transfer path of non-fixed equipment between the current time and the recommended execution time is verified. Once it is confirmed that there is sufficient transfer time, the recommended execution time is written into the preliminary detection plan record of this second type of detection task, and the location of this detection task is determined as the execution location.

[0051] When the resource constraint type of the detection task is type 3, the resource scheduling policy for type 3 is invoked: The third waiting step involves determining the remaining idle time slots for fixed devices in the device ledger database after all first and second type detection tasks have completed resource locking. Specifically, when processing third type detection tasks, the scheduling engine first enters a waiting state until all first and second type detection tasks have completed their respective resource scheduling strategies and completed resource locking. Subsequently, it scans the occupancy time window records of all fixed devices in the device ledger database, divides the entire available time axis according to the locked occupancy time windows, and extracts all remaining idle time slots not occupied by any tasks.

[0052] The third allocation step involves using the remaining idle time slots as candidate execution time windows for the third type of detection task, and locking the fixed equipment and the sample to be damaged within these candidate execution time windows. Specifically, the scheduling engine selects the first remaining idle time slot with a duration not less than the estimated duration of the third type of detection task from the extracted remaining idle time slots, in chronological order, as the candidate execution time window for that task. Within this candidate execution time window, the status of the corresponding fixed equipment in the equipment ledger database is updated to "occupied," and the sample to be damaged is marked as locked. The identifier for locking the task and the candidate execution time window are recorded. Subsequently, this candidate execution time window is used as the suggested execution time, and the location of the fixed equipment is used as the execution location, all of which are written into the preliminary detection plan record for the third type of detection task.

[0053] In step S4, after receiving confirmation instructions from any execution terminal, the preliminary detection plan is locked as the formal detection plan, and the resource occupancy plan in the equipment ledger database is updated. At the same time, the system continuously receives signals from execution terminals. When any execution terminal initiates a plan adjustment request, the system executes an incremental rescheduling algorithm while maintaining the current resource constraints, generates the adjusted detection plan, and updates it synchronously to all execution terminals.

[0054] As an optional implementation, the execution terminal can be any one or more of fixed terminals (such as desktop computers or workstations connected to the system) and mobile terminals (such as smartphones, tablets, or handheld industrial PDAs (portable data acquisition terminals)). Background software can run on the terminal. Upon receiving a confirmation instruction from any execution terminal, the preliminary testing plan is locked as the formal testing plan, and the resource occupancy plan in the equipment ledger database is updated. Specifically, after pushing the preliminary testing plan to each execution terminal, the scheduling engine enters a waiting-for-confirmation state. When a confirmation instruction is first received from any execution terminal, the preliminary testing plan corresponding to that instruction is marked as the formal testing plan, and the confirmation time and the confirmation terminal identifier are recorded. Subsequently, all resource occupancy information involved in the formal testing plan (including the occupancy records of fixed equipment, non-fixed equipment, and samples within the corresponding time window) is permanently written into the resource occupancy plan table of the equipment ledger database as the basic constraint for all subsequent scheduling operations. For preliminary testing plans that have not yet been confirmed by other execution terminals, if their involved time windows or resources overlap with those of locked formal testing plans, the scheduling engine automatically sends a plan status change notification to the corresponding terminal.

[0055] Meanwhile, it continuously receives signals from execution terminals. When any execution terminal initiates a scheme adjustment request (such as including the target detection task identifier and the expected new execution time), it executes an incremental rescheduling algorithm while maintaining the current resource constraints, locking the resource occupancy plans of other tasks in the current formal detection scheme except for the target detection task; with the new execution time as input, it re-executes the resource scheduling strategy corresponding to its resource constraint type only for the target detection task.

[0056] Specifically, the scheduling engine continuously monitors the signals from the execution terminals during system operation. When a scheme adjustment request is received from any execution terminal, the engine first parses the request, extracting the target detection task identifier and the expected new execution time. Then, it reads the resource occupancy plan table from the equipment ledger database and write-protects the resource occupancy records of all other detection tasks in the current formal detection scheme, except for the target detection task, to ensure that these tasks are not affected by subsequent rescheduling operations. Next, it releases the original resource occupancy records of the target detection task (including its original occupied equipment time window and sample lock records). Finally, using the expected new execution time as the start time in the sample usage time period request (the estimated duration follows the original estimated duration of the task), it re-invokes the resource scheduling policy corresponding to its resource constraint type only for the target detection task, and performs conflict detection and time window allocation according to the resource scheduling policy of the corresponding type in step S3.

[0057] If rescheduling is successful, an adjusted detection plan is generated, and the resource usage information of the target detection task is updated in the resource usage plan. If rescheduling fails, a rescheduling failure message carrying the reason for the conflict is returned to the execution terminal. Specifically, if the resource scheduling policy of the corresponding type passes the conflict detection and successfully allocates a new time window during the rescheduling of the target detection task, it is determined that the rescheduling is successful. The original suggested execution time of the task is replaced with the newly allocated time window, an updated detection plan record is generated as the adjusted detection plan, and the newly occupied resource information of the task is updated and written into the resource usage plan table of the equipment ledger database. At the same time, the adjusted detection plan is synchronously pushed to all execution terminals through the communication module.

[0058] If, during the rescheduling process, the corresponding type of resource scheduling policy fails to pass conflict detection (for example, the required equipment or sample has been occupied by other tasks during the expected new execution time), the rescheduling is deemed a failure. No existing resource occupancy plan is modified, and a rescheduling failure message is returned to the execution terminal that initiated the adjustment request. This message carries a description of the conflict cause (such as "the equipment has been occupied during the requested time" or "the sample has been locked by destructive detection during the requested time") so that the end user can understand the cause of the failure and decide on subsequent operations.

[0059] Example 2 This embodiment discloses a prototype vehicle testing scheme execution system based on resource clustering constraints.

[0060] like Figure 3 As shown, a prototype vehicle testing system based on resource clustering constraints includes: The equipment ledger database is configured to store and maintain equipment status information, which includes the fixed attributes, current location, and real-time availability status of each device. The task acquisition module is configured to acquire a set of detection tasks to be executed, wherein each detection task in the detection task set includes a detection item identifier, a required equipment identifier, and a sample constraint label. The resource clustering module is configured to automatically assign each detection task to a matching resource constraint type based on the required equipment identifier and sample constraint label corresponding to each detection task in the detection task set, using a built-in resource clustering model. The scheduling engine module is configured to: based on the resource constraint type of the detection task, call the corresponding resource scheduling strategy, execute multi-level resource conflict detection and time window allocation algorithms to generate a preliminary detection plan for each detection task; The communication module is configured to: push the preliminary detection scheme to the execution terminal and continuously receive instruction feedback; The resource locking module is configured to: upon receiving a confirmation instruction from any execution terminal, lock the preliminary detection plan as the formal detection plan and update the resource usage plan in the equipment ledger database; The rescheduling module is configured to: simultaneously and continuously receive signals from execution terminals; when any execution terminal initiates a scheme adjustment request, execute an incremental rescheduling algorithm while maintaining the current resource constraints, generate an adjusted detection scheme, and synchronously update it to all execution terminals through the communication module.

[0061] Example 3 The purpose of this embodiment is to provide a computer-readable storage medium.

[0062] A computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps in the prototype vehicle testing scheme execution method based on resource clustering constraints as described in Embodiment 1 of this disclosure.

[0063] Example 4 The purpose of this embodiment is to provide an electronic device.

[0064] An electronic device includes a memory, a processor, and a program stored in the memory and executable on the processor. When the processor executes the program, it implements the steps in the prototype vehicle testing scheme execution method based on resource clustering constraints as described in Embodiment 1 of this disclosure.

[0065] The steps and methods involved in the apparatuses of Embodiments 2, 3, and 4 above correspond to those in Embodiment 1. For specific implementation details, please refer to the relevant description section of Embodiment 1. The term "computer-readable storage medium" should be understood as a single medium or multiple media including one or more instruction sets; it should also be understood as including any medium capable of storing, encoding, or carrying an instruction set for execution by a processor and enabling the processor to perform any of the methods in this invention.

[0066] Those skilled in the art will understand that the modules or steps of the present invention described above can be implemented using general-purpose computer devices. Optionally, they can be implemented using computer-executable program code, thereby allowing them to be stored in a storage device for execution by a computer device, or they can be fabricated as separate integrated circuit modules, or multiple modules or steps can be fabricated as a single integrated circuit module. The present invention is not limited to any particular combination of hardware and software.

[0067] While the specific embodiments of the present invention have been described above in conjunction with the accompanying drawings, this is not intended to limit the scope of protection of the present invention. Those skilled in the art should understand that various modifications or variations that can be made by those skilled in the art without creative effort based on the technical solutions of the present invention are still within the scope of protection of the present invention.

Claims

1. A method for implementing a prototype vehicle testing scheme based on resource clustering constraints, characterized in that, include: Obtain the set of testing tasks to be executed and build an equipment ledger database; Based on the required equipment identifiers and sample constraint labels corresponding to each detection task in the detection task set, each detection task is automatically assigned to the matching resource constraint type through a resource clustering model. Based on the resource constraint type of the detection task, the corresponding resource scheduling strategy is invoked, and a multi-level resource conflict detection and time window allocation algorithm is executed to generate a preliminary detection plan for each detection task, which is then pushed to at least one execution terminal to await instruction feedback. Upon receiving confirmation from any execution terminal, the preliminary detection plan is locked as the formal detection plan, and the resource usage plan in the equipment ledger database is updated. At the same time, the system continuously receives signals from execution terminals. When any execution terminal initiates a plan adjustment request, the system executes an incremental rescheduling algorithm while maintaining the current resource constraints, generates the adjusted detection plan, and synchronously updates it to all execution terminals.

2. The prototype vehicle testing scheme execution method based on resource clustering constraints as described in claim 1, characterized in that, The testing task set includes testing item identifiers, required equipment identifiers, and sample constraint labels, wherein the sample constraint labels include destructive labels and non-destructive labels; the equipment status information in the equipment ledger database includes the fixed attributes, current location, and real-time availability status of each device.

3. The prototype vehicle testing scheme execution method based on resource clustering constraints as described in claim 1, characterized in that, The resource clustering model includes a first judgment unit and a second judgment unit; wherein, the first judgment unit is used to determine whether all the equipment required to complete the corresponding detection task has fixed attributes based on the required equipment identifier, and the second judgment unit is used to determine whether the corresponding detection task is a destructive detection based on the sample constraint label; the resource clustering model executes the following inclusion logic based on the output results of the first and second judgment units: When it is determined that all required equipment is fixed and the sample is non-destructive, it is classified as the first type. When it is determined that the required equipment is not all fixed and the sample is non-destructive, it is classified as the second type. When it is determined that all required equipment is fixed and the sample is destroyed, it is classified as the third type.

4. The prototype vehicle testing scheme execution method based on resource clustering constraints as described in claim 1, characterized in that, The resource scheduling strategies implemented for the first type of detection task include: The first resource locking step involves receiving a sample usage time period request sent by the client, wherein the sample usage time period request includes the start time and the estimated duration. The first conflict detection step, based on the equipment ledger database, checks whether the fixed equipment and samples required for the detection task are in an idle state within the time window corresponding to the sample usage period request. In the first allocation step, if the conflict detection is passed, the fixed equipment and sample are locked within the current time window, and this time window is used as the suggested execution time in the preliminary detection plan.

5. The prototype vehicle testing scheme execution method based on resource clustering constraints as described in claim 1, characterized in that, The resource scheduling strategies implemented for the second type of detection task include: The second resource query step involves obtaining the current location of non-fixed equipment required for the testing task based on the equipment ledger database. The second time calculation step involves obtaining the time window and location occupied by the locked first type of detection task after the first type of detection task completes resource locking; The second allocation step involves automatically calculating and pushing an available idle time window as a suggested execution time based on the current location of the non-fixed device and the location of the first type of detection task. The idle time window is located between two adjacent locked time windows and its duration is not less than the estimated duration of the second type of detection task.

6. The prototype vehicle testing scheme execution method based on resource clustering constraints as described in claim 1, characterized in that, The resource scheduling strategies implemented for the third type of detection task include: The third waiting step is to wait until both the first and second type of detection tasks have completed resource locking, and then determine the remaining idle time period of the fixed equipment in the equipment ledger database. The third allocation step involves using the remaining idle time period as a candidate execution time window for the third type of detection task, and locking the fixed equipment and the sample to be destroyed for the third type of detection task within the candidate execution time window.

7. The prototype vehicle testing scheme execution method based on resource clustering constraints as described in claim 1, characterized in that, The implementation of the incremental rescheduling algorithm includes: Receive a scheme adjustment request, which includes the target detection task identifier and the expected new execution time; lock the resource usage plan of other tasks in the current formal detection scheme except for the target detection task; using the new execution time as input, re-execute the resource scheduling strategy corresponding to the resource constraint type of the target detection task only; If rescheduling is successful, an adjusted detection plan is generated, and the resource usage information of the target detection task is updated in the resource usage plan; if rescheduling fails, a rescheduling failure message carrying the reason for the conflict is returned to the execution terminal.

8. A prototype vehicle testing scheme execution system based on resource clustering constraints, characterized in that, include: The equipment ledger database is configured to store and maintain equipment status information, which includes the fixed attributes, current location, and real-time availability status of each device. The task acquisition module is configured to acquire a set of detection tasks to be executed, wherein each detection task in the detection task set includes a detection item identifier, a required equipment identifier, and a sample constraint label. The resource clustering module is configured to automatically assign each detection task to a matching resource constraint type based on the required equipment identifier and sample constraint label corresponding to each detection task in the detection task set, using a built-in resource clustering model. The scheduling engine module is configured to: based on the resource constraint type of the detection task, call the corresponding resource scheduling strategy, execute multi-level resource conflict detection and time window allocation algorithms to generate a preliminary detection plan for each detection task; The communication module is configured to: push the preliminary detection scheme to the execution terminal and continuously receive instruction feedback; The resource locking module is configured to: upon receiving a confirmation instruction from any execution terminal, lock the preliminary detection plan as the formal detection plan and update the resource usage plan in the equipment ledger database; The rescheduling module is configured to: simultaneously and continuously receive signals from execution terminals; when any execution terminal initiates a scheme adjustment request, execute an incremental rescheduling algorithm while maintaining the current resource constraints, generate an adjusted detection scheme, and synchronously update it to all execution terminals through the communication module.

9. A computer-readable storage medium having a program stored thereon, characterized in that, When executed by the processor, the program implements the steps in the prototype vehicle detection scheme execution method based on resource clustering constraints as described in any one of claims 1-7.

10. An electronic device, comprising a memory, a processor, and a program stored in the memory and executable on the processor, characterized in that, When the processor executes the program, it implements the steps in the prototype vehicle detection scheme execution method based on resource clustering constraints as described in any one of claims 1-7.

Images