Firmware transportation method, device and equipment for server room and readable medium
By generating and reconstructing firmware transport tasks, based on historical task information and criticality scores, the problems of waste and damage in the firmware transport process are solved, and timely and efficient transport is achieved.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- GUANGZHOU CLOUDSINO INFORMATION TECH CO LTD
- Filing Date
- 2026-01-15
- Publication Date
- 2026-06-26
Smart Images
Figure CN121543986B_ABST
Abstract
Description
Technical Field
[0001] Embodiments of this disclosure relate to the field of computer technology, and more specifically to firmware delivery methods, apparatus, devices, and readable media for server rooms. Background Technology
[0002] Firmware in data centers often becomes corrupted due to environmental factors, requiring replacement with spare firmware from the firmware repository. However, some firmware (e.g., hard disk drives) is sensitive to vibration, temperature, and humidity changes. Prolonged or improper transportation (such as multiple transshipments or poor storage environments) increases the risk of damage to the read / write heads and platters. Therefore, controlling firmware outbound and transportation times is crucial. Currently, the common approach to controlling firmware outbound and transportation times is to generate a corresponding work order for each task or transportation node, setting fixed execution and transportation times for each work order. The work order determines the response and completion times for different tasks or transportation nodes, and then adjustments are made to the firmware outbound and transportation times accordingly.
[0003] However, when using the above method to control the firmware's outbound and shipping time, the following technical problems often arise:
[0004] When setting fixed execution and transportation times for different work orders, the different completion times for each work order corresponding to different firmware can lead to firmware damage during transportation, resulting in waste of firmware and transportation resources. Furthermore, there are cases where work orders are resubmitted after completion. As a result, when determining the response and completion times of different tasks or transportation nodes through work orders, the situation of resubmitted orders is not taken into account. The adjusted firmware outbound and transportation times do not match the actual times, further causing firmware waste.
[0005] The information disclosed in this background section is only intended to enhance the understanding of the background of the inventive concept, and therefore may contain information that does not constitute prior art known to those skilled in the art. Summary of the Invention
[0006] The summary portion of this disclosure is intended to provide a brief overview of the concepts, which will be described in detail in the detailed description portion. This summary portion is not intended to identify key or essential features of the claimed technical solutions, nor is it intended to limit the scope of the claimed technical solutions.
[0007] Some embodiments of this disclosure provide firmware delivery methods, apparatuses, electronic devices, and computer-readable media for server rooms to address one or more of the technical problems mentioned in the background section above.
[0008] In a first aspect, some embodiments of this disclosure provide a firmware transportation method for a server room. The method includes: responding to receiving a firmware transportation request for a target server room sent by a user terminal; creating a firmware transportation task based on a preset transportation service process template, wherein the firmware transportation task includes at least one task node; obtaining a historical task information set corresponding to the firmware transportation task, wherein the historical task information in the historical task information set corresponds to at least one task node; for each task node in the firmware transportation task, performing the following processing steps: determining node indicator information corresponding to the task node based on each historical task information in the historical task information set, wherein the node indicator information includes: timeout frequency, bottleneck rate, and order replenishment frequency; determining a criticality score corresponding to the task node based on the node indicator information; performing task reconstruction processing on the firmware transportation task based on the generated criticality scores to generate a reconstructed transportation task; and controlling an associated transportation device to transport the firmware corresponding to the firmware transportation request based on the reconstructed transportation task.
[0009] Secondly, some embodiments of this disclosure provide a firmware transport device for a server room. The device includes: a creation unit configured to, in response to receiving a firmware transport request sent by a user terminal, create a firmware transport task based on a preset transport service process template, wherein the firmware transport task includes at least one task node; an acquisition unit configured to acquire a historical task information set corresponding to the firmware transport task, wherein the historical task information in the historical task information set corresponds to at least one task node; an execution unit configured to, for each task node in the firmware transport task, perform the following processing steps: based on each historical task information in the historical task information set, determine the node indicator information corresponding to the task node, wherein the node indicator information includes: timeout frequency, bottleneck rate, and order replenishment frequency; based on the node indicator information, determine the criticality score corresponding to the task node; a task reconstruction unit configured to, based on the generated criticality scores, perform task reconstruction processing on the firmware transport task to generate a reconstructed transport task; and a control unit configured to, based on the reconstructed transport task, control an associated transport device to transport the firmware corresponding to the firmware transport request.
[0010] Thirdly, some embodiments of this disclosure provide an electronic device, including: one or more processors; and a storage device having one or more programs stored thereon, wherein when the one or more programs are executed by the one or more processors, the one or more processors implement the method described in any implementation of the first aspect above.
[0011] Fourthly, some embodiments of this disclosure provide a computer-readable medium having a computer program stored thereon, wherein the program, when executed by a processor, implements the method described in any of the implementations of the first aspect above.
[0012] The above embodiments of this disclosure have the following beneficial effects: the firmware transportation method for server rooms according to some embodiments of this disclosure avoids the waste of firmware and transportation resources. Specifically, the waste of firmware and transportation resources is caused by: generating a corresponding work order for each task or transportation node, setting a fixed execution and transportation time for the work order, determining the response and completion time of different tasks or transportation nodes through the work order, and then adjusting the firmware's outbound and transportation time. Based on this, the firmware transportation method for server rooms according to some embodiments of this disclosure firstly, in response to receiving a firmware transportation request for a target server room sent by a user terminal, a firmware transportation task is created based on a preset transportation service process template. Thus, a task work order for the firmware can be generated when a transportation request for a certain firmware is received. Secondly, the historical task information set corresponding to the above firmware transportation task is obtained. Thus, the historical transportation information of the firmware can be obtained. Then, for each task node in the above firmware transportation task, the following processing steps are performed: First, based on the historical task information in the above historical task information set, the node indicator information corresponding to the above task node is determined. Thus, the historical parameters of each node can be determined through the historical transportation information. Second, based on the aforementioned node indicator information, the criticality score corresponding to each task node is determined. This determines the criticality score of the node for the entire task. Then, based on the generated criticality scores, the firmware transportation task is restructured to generate a restructured transportation task. This restructuring reduces the time required for each task node in the firmware transportation process or adds new task nodes, thereby advancing or delaying the firmware's outbound time. Finally, based on the restructured transportation task, the associated transportation devices are controlled to transport the firmware corresponding to the aforementioned firmware transportation request. This ensures timely and rapid firmware transportation, avoiding situations where firmware is damaged due to prolonged transportation time caused by premature outbound shipment, thus preventing waste of firmware and transportation resources. Attached Figure Description
[0013] The above and other features, advantages, and aspects of the embodiments of this disclosure will become more apparent from the accompanying drawings and the following detailed description. Throughout the drawings, the same or similar reference numerals denote the same or similar elements. It should be understood that the drawings are schematic, and elements are not necessarily drawn to scale.
[0014] Figure 1This is a flowchart of some embodiments of the firmware delivery method for server rooms according to the present disclosure;
[0015] Figure 2 This is a schematic diagram of the structure of some embodiments of the firmware transport device for server rooms according to the present disclosure;
[0016] Figure 3 This is a schematic diagram of the structure of an electronic device suitable for implementing some embodiments of the present disclosure. Detailed Implementation
[0017] Embodiments of this disclosure will now be described in more detail with reference to the accompanying drawings. While some embodiments of this disclosure are shown in the drawings, it should be understood that this disclosure can be implemented in various forms and should not be construed as limited to the embodiments set forth herein. Rather, these embodiments are provided to provide a more thorough and complete understanding of this disclosure. It should be understood that the accompanying drawings and embodiments of this disclosure are for illustrative purposes only and are not intended to limit the scope of protection of this disclosure.
[0018] It should also be noted that, for ease of description, only the parts relevant to the invention are shown in the accompanying drawings. Unless otherwise specified, the embodiments and features described in this disclosure can be combined with each other.
[0019] It should be noted that the concepts of "first" and "second" mentioned in this disclosure are used only to distinguish different devices, modules or units, and are not used to limit the order of functions performed by these devices, modules or units or their interdependencies.
[0020] It should be noted that the terms "a" and "a plurality of" used in this disclosure are illustrative rather than restrictive, and those skilled in the art should understand that, unless otherwise expressly indicated in the context, they should be understood as "one or more".
[0021] The names of messages or information exchanged between multiple devices in the embodiments of this disclosure are for illustrative purposes only and are not intended to limit the scope of such messages or information.
[0022] This disclosure will now be described in detail with reference to the accompanying drawings and embodiments.
[0023] Figure 1 A flow 100 of some embodiments of a firmware delivery method for a server room according to the present disclosure is shown. The firmware delivery method for a server room includes the following steps:
[0024] Step 101: In response to receiving a firmware transport request for the target server room sent by the user terminal, create a firmware transport task based on the preset transport service process template.
[0025] In some embodiments, the execution entity (e.g., a server) of the firmware transportation method for a server room can, in response to receiving a firmware transportation request for a target server room sent by a user terminal, create a firmware transportation task based on a preset transportation service process template. The firmware transportation task includes at least one task node. The user terminal can be a terminal of a user who needs firmware replacement and is connected to the execution entity via a wired or wireless connection. The preset transportation service process template can be a pre-generated transportation service process template. The task node can be a pre-defined firmware transportation task node. For example, the task node can include a waybill generation node. The target server room can be a server room where firmware replacement is required.
[0026] In practice, the following steps can be used to respond to a firmware transport request sent by a user terminal to a target server room, and create a firmware transport task based on a preset transport service process template:
[0027] The first step is to obtain a preset transport service process template in response to receiving a firmware transport request from a user terminal. In practice, firstly, the firmware code required in the firmware transport request can be extracted. Secondly, the preset transport service process template corresponding to the firmware code can be obtained from a target database. This template database can be a pre-set database used to store preset transport service process templates.
[0028] The second step is to determine the current time as the task creation time, and create a firmware transportation task based on the task creation time and the preset transportation service process template.
[0029] The third step is to configure the initial response time and initial completion time for each task node in the firmware transportation task. The initial response time can be a pre-set duration for receiving each task node. The initial completion time can be a pre-set maximum duration for completing a task node.
[0030] Step 102: Obtain the historical task information set for the corresponding firmware transportation task.
[0031] In some embodiments, the executing entity may obtain a set of historical task information corresponding to the firmware transportation task. The historical task information in the set corresponds to at least one task node. The task node information in the at least one task node can represent the completion information of each task node in the historical task information.
[0032] Step 103: For each task node in the firmware transport task, perform the following processing steps:
[0033] Step 1031: Based on the historical task information in the historical task information set, determine the node indicator information corresponding to the task node.
[0034] In some embodiments, the executing entity can determine the node indicator information corresponding to the task node based on the historical task information in the historical task information set. The node indicator information includes: timeout frequency, bottleneck rate, and work order replenishment frequency. The timeout frequency can be the proportion of work orders that time out at the current task node. The bottleneck rate can characterize the probability that a timeout at this node will cause the entire firmware delivery task to time out.
[0035] In addressing the technical problems mentioned in the background section, and considering the application scenario of transporting firmware for core routers and switches in a server room, the following technical issues arise: Firmware for core routers and switches in server rooms is often related to server network partitioning, version upgrades, and security maintenance. If firmware replacement times out during transport, it can lead to upgrade failures, security vulnerabilities, network outages, or even large-scale service paralysis. Numerous replacement orders can disrupt the upgrade sequence, resulting in disordered and unusable upgraded versions. To address the following requirements for this application scenario: accurately determining the historical parameters of the transport task nodes, we have decided to adopt the following solution:
[0036] In practice, the node indicator information corresponding to a task node can be determined based on the historical task information set through the following steps:
[0037] The first step is to select the historical node information corresponding to each of the aforementioned task nodes from the historical task information, forming the target node information set. The target node information set includes response time, completion time, and order completion flag. The completion time represents the time required to complete the current task node. The response time represents the response time required to accept the current task node. The order completion flag indicates whether an order completion has occurred at the current node.
[0038] The second step is to determine the replenishment frequency for each of the corresponding replenishment markers. In practice, the replenishment frequency can be determined as the ratio of the number of replenishment markers indicating that a replenishment has occurred to the total number of replenishment markers.
[0039] The third step is to select at least one historical task from the aforementioned historical task information that meets the preset completion time condition, and use this as the timeout task information set. The preset completion time condition can be historical task information whose completion time exceeds the corresponding initial completion time.
[0040] The fourth step is to determine the timeout frequency by the ratio of the number of timeout task information included in the above-mentioned timeout task information set to the number of historical task information included in the above-mentioned historical task information set.
[0041] The fifth step is to determine the bottleneck rate by the ratio of the number of timeout task information included in the above timeout task information set to the number of timeout task information whose total completion time is greater than or equal to the preset total completion time threshold.
[0042] The sixth step is to combine the above-mentioned order replenishment frequency, timeout frequency, and bottleneck rate into node indicator information.
[0043] The first to sixth steps described above, as an inventive point of this disclosure, combined with step "105" below, solve the technical problem: "Firmware devices such as core routers and switches in server rooms are often related to server network partitioning, version upgrades, and security maintenance. If firmware replacement times out during transportation, it leads to version upgrade failure, security policy vulnerabilities, and consequently, network interruption or even large-scale service paralysis." The reasons for network interruption or even large-scale service paralysis are as follows: Firmware devices such as core routers and switches in server rooms are often related to server network partitioning, version upgrades, and security maintenance. If firmware replacement times out during transportation, it leads to version upgrade failure, security policy vulnerabilities, and consequently, network interruption or even large-scale service paralysis. Solving these factors can avoid network interruption or even large-scale service paralysis. To achieve this effect, this disclosure, firstly, selects historical node information corresponding to the aforementioned task nodes from the aforementioned historical task information, as a target node information set. Thus, the historical information of a certain task node can be selected. Secondly, based on the corresponding order replenishment markers, the order replenishment frequency corresponding to the aforementioned task node is determined. Therefore, the frequency of order replenishment at the current node can be determined to identify whether an upgrade sequence error has occurred. Third, at least one historical task that meets the preset completion time condition is selected from the aforementioned historical task information and used as the timeout task information set. This allows the identification of each timeout task. Fourth, the ratio of the number of timeout tasks in the timeout task information set to the number of historical tasks in the historical task information set is determined as the timeout frequency; the ratio of the number of timeout tasks in the timeout task information set to the number of timeout tasks whose total completion time is greater than or equal to a preset total completion time threshold is determined as the bottleneck rate; the order replenishment frequency, the timeout frequency, and the bottleneck rate are combined to form node indicator information. This generates the indicator information for the current node. Combined with step "Step 105" below, based on the reconstructed transportation task, the associated transportation device is controlled to transport the firmware corresponding to the firmware transportation request. This allows the use of a backup transportation scheme when the generated order replenishment frequency, timeout frequency, and bottleneck rate are high, avoiding timeout firmware transportation and thus preventing network interruptions or even large-scale service paralysis.
[0044] Step 1032: Determine the criticality score corresponding to the task node based on the node indicator information.
[0045] In some embodiments, the execution entity may determine the criticality score corresponding to the task node based on the node indicator information.
[0046] In practice, the criticality score of a task node can be determined based on node metric information through the following steps:
[0047] The first step is to obtain the task weights of the aforementioned task nodes. These task weights can be pre-defined weights for the task nodes.
[0048] The second step is to determine the average response time and average completion time of the above task nodes based on the target node information set mentioned above.
[0049] The third step is to determine the average completion rate corresponding to the above-mentioned task nodes based on the above-mentioned average response time, average completion time, initial response time, and initial completion time.
[0050] The fourth step is to determine the criticality score for each task node based on the average completion rate and the corresponding node metrics. In practice, the criticality score can be determined using a linear weighting formula.
[0051] Step 104: Based on the generated key scores, perform task reconstruction processing on the firmware transportation task to generate a reconstructed transportation task.
[0052] In some embodiments, the aforementioned execution entity may perform task reconstruction processing on the aforementioned firmware transportation task based on the generated key scores, so as to generate a reconstructed transportation task.
[0053] In practice, the firmware delivery task can be refactored based on the generated criticality scores using the following steps to generate a refactored delivery task:
[0054] The first step is to perform task reconstruction processing on each task node in the firmware transportation task, in response to the criticality score of the task node being less than or equal to a preset score threshold, to generate a reconstructed task node. The preset score threshold can be a pre-defined criticality score.
[0055] In addressing the technical problems mentioned in the background section, and specifically in the application scenario of transporting replacement disks for damaged disks in a RAID (Redundant Array of Independent Disks) array in a server room, the following technical issues arise: When a damaged disk exists in the RAID array, degraded operation is required, posing a risk of data loss. Furthermore, various factors can impact the transportation task (e.g., insufficient outbound equipment), causing the current task node to fail to complete on time, requiring reordering. Additionally, the task nodes are lengthy, and the timeout point cannot be determined, leading to data loss in the RAID array. Considering the following requirements for this application scenario: determining the specific point of timeout during transportation, we decided to adopt the following solution:
[0056] In practice, for each task node in the firmware transportation task described above, in response to the criticality score corresponding to the task node being less than or equal to a preset score threshold, the task node can be refactored using the following sub-steps to generate a refactored task node:
[0057] The first sub-step involves performing the following reconstruction steps for each task node in the firmware transportation task, in response to the criticality score corresponding to the task node being less than or equal to a preset score threshold:
[0058] The first reconstruction step involves determining the discrete value of completion time based on the target node information set corresponding to the task node, in response to the task node's order replenishment frequency being greater than or equal to a preset order replenishment frequency. This discrete value can be the standard deviation of the completion time.
[0059] The second reconstruction step involves obtaining the target historical log information corresponding to the task node in response to the aforementioned discrete value of completion time being greater than or equal to a preset discrete threshold. This target historical log information can be behavioral logs of the task node within a historical time period.
[0060] The third reconstruction step involves extracting keywords from the aforementioned target historical log information to generate a log keyword set. In practice, specific keywords can be set and extracted using the TF-IDF algorithm.
[0061] The fourth reconstruction step involves dividing the aforementioned task nodes into subtasks based on the log keyword set, thereby generating a subtask set. Here, semantic recognition can be performed on keywords whose frequency of occurrence is greater than or equal to a preset frequency, and subtasks corresponding to keywords representing delays can be generated.
[0062] The fifth refactoring step involves determining the relationships between the various subtasks in the aforementioned subtask set. These relationships can include sequential and parallel relationships. A sequential relationship indicates that the subtasks are processed sequentially. A parallel relationship indicates that the subtasks can be processed in parallel.
[0063] The sixth reconstruction step involves generating a subtask association graph based on the aforementioned relationship information, and then generating subtask response time groups and subtask completion time groups based on this graph. In practice, firstly, a tree-like subtask association graph can be generated using the relationship information. Secondly, the initial response time and initial completion time corresponding to the aforementioned task nodes can be divided using an average partitioning method to generate subtask response time groups and subtask completion time groups.
[0064] The seventh reconstruction step involves reconstructing the task nodes based on the aforementioned subtask association graph, subtask response time groups, and subtask completion time groups to generate reconstructed task nodes. In practice, the task nodes can be replaced with the aforementioned subtask sets to perform task reconstruction on the task nodes and generate reconstructed task nodes.
[0065] The first to seventh reconstruction steps described above, as an inventive point of this disclosure, combined with step "105" below, solve the technical problem: "When a damaged disk exists in the RAID array, it needs to be degraded, posing a risk of data loss. During transportation tasks, various situations affecting the task (e.g., insufficient outbound equipment) can prevent the current task node from completing on time, requiring reorders. Furthermore, the task nodes are often long, making it impossible to determine the timeout period, leading to data loss in the RAID array." The reasons for data loss in the RAID array are as follows: When a damaged disk exists in the RAID array, it needs to be degraded, posing a risk of data loss. During transportation tasks, various situations affecting the task (e.g., insufficient outbound equipment) can prevent the current task node from completing on time, requiring reorders. Furthermore, the task nodes are often long, making it impossible to determine the timeout period, leading to data loss in the RAID array. Solving these factors can prevent data loss in the RAID array. To achieve this effect, this disclosure firstly, for each task node in the aforementioned firmware transportation task, in response to the criticality score corresponding to the task node being less than or equal to a preset score threshold, performs the following reconstruction steps: First, in response to the order replenishment frequency corresponding to the task node being greater than or equal to a preset order replenishment frequency, based on the target node information set corresponding to the task node, determines the discrete value of completion time. This allows determination of the dispersion of the current node's completion time, thereby determining the range of the current node's completion time. Second, in response to the aforementioned discrete value of completion time being greater than or equal to a preset discrete threshold, obtain the target historical log information corresponding to the task node. This allows determination of the reasons for the current task node's long completion time. Third, perform keyword extraction processing on the aforementioned target historical log information to generate a log keyword set. This allows extraction of keywords representing delays from the historical logs. Fourth, based on the aforementioned log keyword set, divide the task node into subtasks to generate a subtask set. This allows setting the stage corresponding to the delay keyword as a subtask node, thereby enabling control over each delayed subtask node. Fifth, determine the relationship information of each subtask in the above subtask set; based on the above relationship information, generate a subtask relationship graph, and based on the above subtask relationship graph, generate subtask response time groups and subtask completion time groups. Thus, response times and completion times can be configured according to the relationship of each subtask. Sixth, based on the above subtask relationship graph, the above subtask response time groups, and the above subtask completion time groups, perform task reconstruction processing on the above task nodes to generate reconstructed task nodes. Thus, task nodes can be reconstructed. Combined with step "Step 105" below, based on the reconstructed transportation task, control the associated transportation device to transport the firmware corresponding to the firmware transportation request.Therefore, firmware can be transported through the reconstructed task nodes, and response and completion times can be set for different sub-task nodes. This allows for accurate identification of nodes where timeouts occur, and the use of backup schemes for nodes that time out during transport, thereby avoiding data loss in the RAID array due to transport timeouts.
[0066] The second step is to combine the generated reconstructed task nodes with the unreconstructed task nodes to form a reconstructed transportation task.
[0067] Step 105: Based on the reconstructed transportation task, control the associated transportation device to transport the firmware corresponding to the firmware transportation request.
[0068] In some embodiments, the aforementioned executing entity may, based on the aforementioned reconstructed transportation task, control the associated transportation device to transport the firmware corresponding to the aforementioned firmware transportation request.
[0069] In addressing the technical problems mentioned in the background section, and considering the specific application scenario of transporting SSDs (Solid State Disks), the following technical issues arise: New SSDs, when powered off, experience slow charge loss. Prolonged transit and transportation (especially at high temperatures) can shorten data retention or cause errors in pre-stored firmware / data, rendering the SSD unusable. To meet the specific requirements of this application scenario—avoiding SSD damage during prolonged transportation—we have decided to adopt the following solution:
[0070] In some optional implementations of certain embodiments, the aforementioned execution entity can control the associated transportation device to transport the firmware corresponding to the firmware transportation request based on the reconstructed transportation task through the following steps:
[0071] The first step is to obtain the instruction template for each task node in the aforementioned reconstructed transportation task. This instruction template can be a pre-defined template used to fill in task parameters.
[0072] The second step involves extracting the task parameters for the reconstructed transportation task and generating firmware transportation instructions for each task node based on the instruction template. In practice, task parameters can be extracted from the reconstructed transportation task and filled into the instruction template. These task parameters may include, but are not limited to: transportation equipment code, starting address, destination address, and planned departure time.
[0073] The third step involves sending the corresponding firmware transport command to the transport device in response to the current time being the preset execution time of the target task node. The preset execution time can be a pre-defined start time for a specific task node.
[0074] The fourth step involves acquiring a transportation dataset based on the associated transportation data acquisition device. This transportation dataset can contain transportation status data during the transportation process. For example, the transportation data may include, but is not limited to, transportation location, transportation speed, and transportation temperature. The transportation data acquisition device can be a data acquisition device pre-deployed within the transportation vehicle. This device may include, but is not limited to, GPS and temperature sensors.
[0075] Fifth, based on the aforementioned transportation dataset, determine the node progress deviation value for the target task node. In practice, the ratio of the completion time of the target task node to the preset completion time can be used to determine the node progress deviation value.
[0076] Step 6: In response to the aforementioned node progress deviation value being greater than or equal to a preset deviation threshold, and the criticality score corresponding to the aforementioned target task node being greater than or equal to a preset criticality score, a candidate transportation instruction corresponding to the aforementioned target task node is generated. The aforementioned preset deviation threshold can be a pre-set node progress deviation value. In practice, in response to the aforementioned node progress deviation value being greater than or equal to the preset deviation threshold, and the aforementioned criticality score corresponding to the aforementioned target task node being greater than or equal to a preset criticality score, a candidate transportation instruction different from the current transportation instruction can be selected from the candidate transportation instruction library.
[0077] In practice, the following sub-steps can be used to generate alternative transportation instructions for the aforementioned target task node in response to the above-mentioned node progress deviation value being greater than or equal to a preset deviation threshold, and the criticality score corresponding to the above-mentioned target task node being greater than or equal to a preset criticality score:
[0078] The first sub-step involves determining whether there is backup transportation information for the target task node if the progress deviation value of the aforementioned node is greater than or equal to a preset deviation threshold, and the criticality score corresponding to the aforementioned target task node is greater than or equal to a preset criticality score. The backup transportation information can be a pre-set backup transportation plan for a specific task node.
[0079] The second sub-step involves, in response to the presence of backup transportation information corresponding to the target task node, and the backup transportation information indicating the existence of a backup transportation device, generating a transportation instruction to control the backup transportation device as a candidate transportation instruction, and, based on the candidate transportation instruction, controlling the backup transportation device to the transportation location for firmware transportation. The backup transportation device may be a pre-set device used to replace the existing transportation device for firmware transportation.
[0080] The third sub-step is to generate a transportation instruction to change the transportation route in response to the availability of backup transportation information corresponding to the target task node. This backup transportation information indicates the existence of backup transportation routes.
[0081] The fourth sub-step involves updating the completion time of the next task node in response to the lack of backup transportation information for the target task node, and generating an instruction based on this completion time to update the transportation parameters of the transportation device as an alternative transportation instruction. In practice, firstly, the ratio of the timeout portion of the target task node to its corresponding completion time can be determined as the timeout value. Secondly, the completion time of the next task node is proportionally shortened according to the aforementioned timeout value to obtain a shortened completion time. Thirdly, based on the shortened completion time, the transportation speed and route of the transportation equipment are determined, and an instruction to change the transportation speed and route is generated.
[0082] The seventh step is to send the aforementioned alternative transportation instructions to the aforementioned transportation device to control the aforementioned transportation device to carry out the alternative transportation.
[0083] Steps one through seven above, as an inventive point of this disclosure, solve the technical problem: "When a brand-new SSD is powered off, its charge will slowly dissipate. Prolonged transit and transportation (especially at high temperatures) may shorten the data retention period or cause errors in the pre-stored firmware / data, resulting in SSD damage and unusability." The reasons for SSD damage and unusability are as follows: When a brand-new SSD is powered off, its charge will slowly dissipate. Prolonged transit and transportation (especially at high temperatures) may shorten the data retention period or cause errors in the pre-stored firmware / data, resulting in SSD damage and unusability. Solving these factors can avoid SSD damage and unusability due to prolonged transportation. To achieve this effect, this disclosure firstly obtains the instruction template for each task node in the aforementioned reconstruction and transportation task; extracts the task parameters of the aforementioned reconstruction and transportation task; and generates a firmware transportation instruction corresponding to each task node based on the instruction template. Thus, a transportation instruction corresponding to each task node can be generated. Secondly, in response to the current time being the preset execution time of the target task node, the corresponding firmware transportation instruction is sent to the aforementioned transportation device. Thus, the firmware can be transported. Third, based on the associated transportation data acquisition device, a transportation dataset is acquired. This allows for the collection of transportation status data during the transportation process. Fourth, based on the aforementioned transportation dataset, the node progress deviation value of the target task node is determined. In response to the node progress deviation value being greater than or equal to a preset deviation threshold, and the criticality score corresponding to the target task node being greater than or equal to a preset criticality score, an alternative transportation instruction corresponding to the target task node is generated. This allows for the activation of a backup transportation plan when the deviation value is large. Fifth, the alternative transportation instruction is sent to the transportation device to control the transportation device to perform the alternative transportation. This allows for timely adjustment of the transportation method using a backup plan, thereby avoiding the situation where prolonged transportation leads to SSD damage and unusability.
[0084] The above embodiments of this disclosure have the following beneficial effects: the firmware transportation method for server rooms according to some embodiments of this disclosure avoids the waste of firmware and transportation resources. Specifically, the waste of firmware and transportation resources is caused by: generating a corresponding work order for each task or transportation node, setting a fixed execution and transportation time for the work order, determining the response and completion time of different tasks or transportation nodes through the work order, and then adjusting the firmware's outbound and transportation time. Based on this, the firmware transportation method for server rooms according to some embodiments of this disclosure firstly, in response to receiving a firmware transportation request for a target server room sent by a user terminal, a firmware transportation task is created based on a preset transportation service process template. Thus, a task work order for the firmware can be generated when a transportation request for a certain firmware is received. Secondly, the historical task information set corresponding to the above firmware transportation task is obtained. Thus, the historical transportation information of the firmware can be obtained. Then, for each task node in the above firmware transportation task, the following processing steps are performed: First, based on the historical task information in the above historical task information set, the node indicator information corresponding to the above task node is determined. Thus, the historical parameters of each node can be determined through the historical transportation information. Second, based on the aforementioned node indicator information, the criticality score corresponding to each task node is determined. This determines the criticality score of the node for the entire task. Then, based on the generated criticality scores, the firmware transportation task is restructured to generate a restructured transportation task. This restructuring reduces the time required for each task node in the firmware transportation process or adds new task nodes, thereby advancing or delaying the firmware's outbound time. Finally, based on the restructured transportation task, the associated transportation devices are controlled to transport the firmware corresponding to the aforementioned firmware transportation request. This ensures timely and rapid firmware transportation, avoiding situations where firmware is damaged due to prolonged transportation time caused by premature outbound shipment, thus preventing waste of firmware and transportation resources.
[0085] Further reference Figure 2 As an implementation of the methods shown in the above figures, this disclosure provides some embodiments of a firmware delivery device for a server room, these device embodiments being similar to... Figure 1 Corresponding to the method embodiments shown, this firmware delivery device for server rooms can be specifically applied to various electronic devices.
[0086] like Figure 2As shown, some embodiments of the firmware transport device 200 for server rooms include: a creation unit 201, an acquisition unit 202, an execution unit 203, a task reconstruction unit 204, and a control unit 205. The creation unit 201 is configured to, in response to receiving a firmware transport request sent by a user terminal, create a firmware transport task based on a preset transport service process template, wherein the firmware transport task includes at least one task node; the acquisition unit 202 is configured to acquire a historical task information set corresponding to the firmware transport task, wherein the historical task information in the historical task information set corresponds to at least one task node; the execution unit 203 is configured to, for each task node in the firmware transport task, perform the following processing steps: based on each historical task information in the historical task information set, determine the node indicator information corresponding to the task node, wherein the node indicator information includes: timeout frequency, bottleneck rate, and order replenishment frequency; based on the node indicator information, determine the criticality score corresponding to the task node; the task reconstruction unit 204 is configured to, based on the generated criticality scores, perform task reconstruction processing on the firmware transport task to generate a reconstructed transport task; and the control unit 205 is configured to, based on the reconstructed transport task, control the associated transport device to transport the firmware corresponding to the firmware transport request.
[0087] It is understandable that the units described in the firmware delivery device 200 for server rooms are similar to those in the reference. Figure 1 The steps in the described method correspond to each other. Therefore, the operations, features, and beneficial effects described above for the method also apply to the firmware transport device 200 for server rooms and the units contained therein, and will not be repeated here.
[0088] The following is for reference. Figure 3 This document illustrates a structural schematic of an electronic device 300 suitable for implementing some embodiments of the present disclosure. The electronic devices in some embodiments of the present disclosure may include, but are not limited to, mobile terminals such as mobile phones, laptops, digital broadcast receivers, PDAs (personal digital assistants), PADs (tablet computers), PMPs (portable multimedia players), in-vehicle terminals (e.g., in-vehicle navigation terminals), and fixed terminals such as digital TVs and desktop computers. Figure 3 The electronic device shown is merely an example and should not be construed as limiting the functionality and scope of the embodiments of this disclosure.
[0089] like Figure 3As shown, the electronic device 300 may include a processing unit 301 (e.g., a central processing unit, a graphics processor, etc.), which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 302 or a program loaded from a storage device 308 into a random access memory (RAM) 303. The RAM 303 also stores various programs and data required for the operation of the electronic device 300. The processing unit 301, ROM 302, and RAM 303 are interconnected via a bus 304. An input / output (I / O) interface 305 is also connected to the bus 304.
[0090] Typically, the following devices can be connected to I / O interface 305: input devices 306 including, for example, touchscreens, touchpads, keyboards, mice, cameras, microphones, accelerometers, gyroscopes, etc.; output devices 307 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 308 including, for example, magnetic tapes, hard disks, etc.; and communication devices 309. Communication device 309 allows electronic device 300 to communicate wirelessly or wiredly with other devices to exchange data. Although Figure 3 An electronic device 300 with various devices is shown; however, it should be understood that it is not required to implement or possess all of the devices shown. More or fewer devices may be implemented or possessed alternatively. Figure 3 Each box shown can represent a device or multiple devices as needed.
[0091] In particular, according to some embodiments of this disclosure, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, some embodiments of this disclosure include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication device 309, or installed from storage device 308, or installed from ROM 302. When the computer program is executed by processing device 301, it performs the functions defined in the methods of some embodiments of this disclosure.
[0092] It should be noted that, in some embodiments of this disclosure, the computer-readable medium may be a computer-readable signal medium or a computer-readable storage medium, or any combination thereof. A computer-readable storage medium may be, for example,—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In some embodiments of this disclosure, a computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. In some embodiments of this disclosure, a computer-readable signal medium may include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A computer-readable signal medium can be any computer-readable medium other than a computer-readable storage medium, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to: wires, optical fibers, RF (radio frequency), etc., or any suitable combination thereof.
[0093] In some implementations, clients and servers can communicate using any currently known or future-developed network protocol such as HTTP (Hypertext Transfer Protocol) and can interconnect with digital data communication (e.g., communication networks) of any form or medium. Examples of communication networks include local area networks (“LANs”), wide area networks (“WANs”), the Internet (e.g., the Internet of Things), and peer-to-peer networks (e.g., ad hoc peer-to-peer networks), as well as any currently known or future-developed networks.
[0094] The aforementioned computer-readable medium may be included in the aforementioned electronic device; or it may exist independently and not assembled into the electronic device. The aforementioned computer-readable medium carries one or more programs, which, when executed by the electronic device, cause the electronic device to: respond to receiving a firmware transport request for a target server room sent by a user terminal; create a firmware transport task based on a preset transport service process template, wherein the firmware transport task includes at least one task node; obtain a historical task information set corresponding to the aforementioned firmware transport task, wherein the historical task information in the historical task information set corresponds to at least one task node information; for each task node in the aforementioned firmware transport task, perform the following processing steps: based on each historical task information in the aforementioned historical task information set, determine the node indicator information corresponding to the aforementioned task node, wherein the node indicator information includes: timeout frequency, bottleneck rate, and order replenishment frequency; based on the aforementioned node indicator information, determine the criticality score corresponding to the aforementioned task node; based on the generated criticality scores, perform task reconstruction processing on the aforementioned firmware transport task to generate a reconstructed transport task; based on the reconstructed transport task, control the associated transport device to transport the firmware corresponding to the aforementioned firmware transport request.
[0095] Computer program code for performing operations of some embodiments of this disclosure can be written in one or more programming languages or a combination thereof, including object-oriented programming languages such as Java, Smalltalk, and C++, and conventional procedural programming languages such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).
[0096] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this disclosure. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.
[0097] The units described in some embodiments of this disclosure can be implemented in software or hardware. The described units can also be housed in a processor; for example, a processor may be described as including a creation unit, an acquisition unit, an execution unit, a task reconfiguration unit, and a control unit. The names of these units do not necessarily limit the unit itself; for example, the creation unit may also be described as "a unit that, in response to receiving a firmware transport request from a user terminal for a target server room, creates a firmware transport task based on a preset transport service process template."
[0098] The functions described above in this document can be performed at least in part by one or more hardware logic components. For example, exemplary types of hardware logic components that can be used, without limitation, include: field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), system-on-a-chip (SoCs), complex programmable logic devices (CPLDs), and so on.
[0099] The above description is merely a selection of preferred embodiments of this disclosure and an explanation of the technical principles employed. Those skilled in the art should understand that the scope of the invention involved in the embodiments of this disclosure is not limited to technical solutions formed by specific combinations of the above-described technical features, but should also cover other technical solutions formed by arbitrary combinations of the above-described technical features or their equivalents without departing from the above-described inventive concept. For example, technical solutions formed by substituting the above-described features with (but not limited to) technical features with similar functions disclosed in the embodiments of this disclosure.
Claims
1. A firmware delivery method for server room use, comprising: In response to receiving a firmware transport request for a target server room sent by a user terminal, a firmware transport task is created based on a preset transport service process template. The firmware transport task includes at least one task node. An initial response time and an initial completion time are configured for each task node in the firmware transport task. The initial response time is a preset duration for receiving each task node, and the initial completion time is a preset maximum duration for completing the task node. Obtain the historical task information set corresponding to the firmware transportation task, wherein the historical task information set corresponds to at least one task node information; For each task node in the firmware transport task, the following processing steps are performed: Based on the historical task information in the historical task information set, the node indicator information corresponding to the task node is determined, wherein the node indicator information includes: timeout frequency, bottleneck rate and order replenishment frequency. Based on the node indicator information, the initial response time, and the initial completion time, the criticality score corresponding to the task node is determined; Based on the generated key scores, the firmware transportation task is reconstructed to generate a reconstructed transportation task. Based on the reconstructed transportation task, controlling the associated transportation device to transport the firmware corresponding to the firmware transportation request includes: obtaining the instruction template of each task node in the reconstructed transportation task; extracting the task parameters of the reconstructed transportation task, and generating a firmware transportation instruction corresponding to each task node based on the instruction template; in response to the current time being the preset execution time of the target task node, sending the corresponding firmware transportation instruction to the transportation device; acquiring a transportation dataset based on an associated transportation data acquisition device; determining the node progress deviation value of the target task node based on the transportation dataset; in response to the node progress deviation value being greater than or equal to a preset deviation threshold, and the criticality score corresponding to the target task node being greater than or equal to a preset criticality score, generating a candidate transportation instruction corresponding to the target task node; and sending the candidate transportation instruction to the transportation device to control the transportation device to perform the selection. Transportation; wherein, in response to the node progress deviation value being greater than or equal to a preset deviation threshold, and the criticality score corresponding to the target task node being greater than or equal to a preset criticality score, it is determined whether the target task node corresponds to backup transportation information; in response to the target task node corresponding to backup transportation information, and the backup transportation information indicating the existence of a backup transportation device, a transportation instruction for controlling the backup transportation device is generated as a candidate transportation instruction, and based on the candidate transportation instruction, the backup transportation device is controlled to proceed to the transportation location for firmware transportation; in response to the target task node corresponding to backup transportation information, and the backup transportation information indicating the existence of a backup transportation route, a transportation instruction for changing the transportation route is generated as a candidate transportation instruction; in response to the target task node not corresponding to backup transportation information, the completion time of the next task node is updated, and based on the completion time, an instruction for updating the transportation parameters of the transportation device is generated as a candidate transportation instruction. The step of performing task reconstruction processing on the firmware transportation task based on the generated key scores to generate a reconstructed transportation task includes: For each task node in the firmware transportation task, in response to the criticality score corresponding to the task node being less than or equal to a preset score threshold, the task node is refactored to generate a refactored task node, including: for each task node in the firmware transportation task, in response to the criticality score corresponding to the task node being less than or equal to a preset score threshold, the following refactoring steps are performed: in response to the order replenishment frequency corresponding to the task node being greater than or equal to a preset order replenishment frequency, based on the target node information set corresponding to the task node, a discrete value of completion time is determined; in response to the discrete value of completion time being greater than or equal to a preset discrete threshold, the task is obtained. The system retrieves target historical log information corresponding to a node; extracts keywords from the target historical log information to generate a log keyword set; divides the task node into subtasks based on the log keyword set to generate a subtask set; determines the association information of each subtask in the subtask set; generates a subtask association graph based on the association information, and generates subtask response time groups and subtask completion time groups based on the subtask association graph; and performs task reconstruction processing on the task node based on the subtask association graph, the subtask response time groups, and the subtask completion time groups to generate reconstructed task nodes. The generated reconstructed task nodes are combined with the unreconstructed task nodes to form a reconstructed transportation task.
2. The method according to claim 1, wherein, The step of responding to a firmware transport request sent by a user terminal for a target server room involves creating a firmware transport task based on a preset transport service process template, including: In response to receiving a firmware transport request from a user terminal, a preset transport service process template is obtained; The current time is determined as the task creation time, and a firmware transportation task is created based on the task creation time and the preset transportation service process template.
3. The method according to claim 2, wherein, The process of determining the criticality score corresponding to the task node based on the node indicator information, the initial response time, and the initial completion time includes: Obtain the task weight of the task node; Based on the target node information set, determine the average response time and average completion time of the task node; Based on the average response time, the average completion time, the initial response time, and the initial completion time, determine the average completion rate corresponding to the task node; Based on the average completion rate and the node indicator information corresponding to the task node, the criticality score corresponding to the task node is determined.
4. The method according to claim 1, wherein, The step of determining the node indicator information corresponding to the task node based on the historical task information set includes: Select the historical node information corresponding to the task node from the historical task information to form the target node information set, wherein the target node information in the target node information set includes response time, completion time and order completion flag. Based on the corresponding order completion markers, determine the order completion frequency corresponding to the task node; Select at least one historical task information that meets the preset completion time condition from the various historical task information, and use it as the timeout task information set; The ratio of the number of timeout task information included in the timeout task information set to the number of historical task information included in the historical task information set is determined as the timeout frequency; The bottleneck rate is determined by the ratio of the number of timeout task information included in the timeout task information set to the number of timeout task information whose total completion time is greater than or equal to a preset total completion time threshold. The order replenishment frequency, the timeout frequency, and the bottleneck rate are combined into node indicator information.
5. A firmware delivery device for a server room, comprising: The creation unit is configured to respond to receiving a firmware transport request sent by a user terminal and create a firmware transport task based on a preset transport service process template. The firmware transport task includes at least one task node. An initial response time and an initial completion time are configured for each task node in the firmware transport task. The initial response time is a preset duration for receiving each task node, and the initial completion time is a preset maximum duration for completing the task node. The acquisition unit is configured to acquire a set of historical task information corresponding to the firmware transportation task, wherein the historical task information in the set of historical task information corresponds to at least one task node information. The execution unit is configured to perform the following processing steps for each task node in the firmware transportation task: based on the historical task information in the historical task information set, determine the node indicator information corresponding to the task node, wherein the node indicator information includes: timeout frequency, bottleneck rate, and order replenishment frequency; based on the node indicator information, the initial response time, and the initial completion time, determine the criticality score corresponding to the task node; The task reconstruction unit is configured to perform task reconstruction processing on the firmware transport task based on the generated key scores to generate a reconstructed transport task. A control unit, configured to control an associated transportation device to transport firmware corresponding to the firmware transport request based on the reconstructed transportation task, includes: acquiring an instruction template for each task node in the reconstructed transportation task; extracting task parameters of the reconstructed transportation task, and generating a firmware transportation instruction corresponding to each task node based on the instruction template; sending the corresponding firmware transportation instruction to the transportation device in response to the current time being a preset execution time of the target task node; acquiring a transportation dataset based on an associated transportation data acquisition device; determining the node progress deviation value of the target task node based on the transportation dataset; generating a candidate transportation instruction corresponding to the target task node in response to the node progress deviation value being greater than or equal to a preset deviation threshold and the criticality score corresponding to the target task node being greater than or equal to a preset criticality score; and sending the candidate transportation instruction to the transportation device to control the transportation device. Alternative transportation is performed; wherein, in response to the node progress deviation value being greater than or equal to a preset deviation threshold, and the criticality score corresponding to the target task node being greater than or equal to a preset criticality score, it is determined whether the target task node corresponds to backup transportation information; in response to the target task node corresponding to backup transportation information, and the backup transportation information indicating the existence of a backup transportation device, a transportation instruction for controlling the backup transportation device is generated as an alternative transportation instruction, and based on the alternative transportation instruction, the backup transportation device is controlled to proceed to the transportation location for firmware transportation; in response to the target task node corresponding to backup transportation information, and the backup transportation information indicating the existence of a backup transportation route, a transportation instruction for changing the transportation route is generated as an alternative transportation instruction; in response to the target task node not corresponding to backup transportation information, the completion time of the next task node is updated, and based on the completion time, an instruction for updating the transportation parameters of the transportation device is generated as an alternative transportation instruction. The task reconstruction unit is further configured as follows: For each task node in the firmware transportation task, in response to the criticality score corresponding to the task node being less than or equal to a preset score threshold, the task node is refactored to generate a refactored task node, including: for each task node in the firmware transportation task, in response to the criticality score corresponding to the task node being less than or equal to a preset score threshold, the following refactoring steps are performed: in response to the order replenishment frequency corresponding to the task node being greater than or equal to a preset order replenishment frequency, based on the target node information set corresponding to the task node, a discrete value of completion time is determined; in response to the discrete value of completion time being greater than or equal to a preset discrete threshold, the task is obtained. The system retrieves target historical log information corresponding to a node; extracts keywords from the target historical log information to generate a log keyword set; divides the task node into subtasks based on the log keyword set to generate a subtask set; determines the association information of each subtask in the subtask set; generates a subtask association graph based on the association information, and generates subtask response time groups and subtask completion time groups based on the subtask association graph; and performs task reconstruction processing on the task node based on the subtask association graph, the subtask response time groups, and the subtask completion time groups to generate reconstructed task nodes. The generated reconstructed task nodes are combined with the unreconstructed task nodes to form a reconstructed transportation task.
6. An electronic device, comprising: One or more processors; A storage device on which one or more programs are stored; When the one or more programs are executed by the one or more processors, the one or more processors implement the method as described in any one of claims 1 to 4.
7. A computer-readable medium having a computer program stored thereon, wherein, When the program is executed by the processor, it implements the method as described in any one of claims 1 to 4.