Modular logistics system data analysis method and system

Abstract

The application provides a modular logistics system data analysis method and system, relates to the technical field of data analysis of a logistics system, can accurately understand the influence of parameter change of a bottom layer component on the device function and performance of an upper layer, and dynamically adjusts calculation logic according to the specific relationship between the component and the device, so that the parameter change of the bottom layer can be accurately conducted and reflected in the performance index of the upper layer device, and accurate maintenance of cross-level data authenticity is realized.

Description

Technical Field

[0001] This application relates to the field of data analysis technology for logistics systems, and more specifically, to a modular logistics system data analysis method and system. Background Technology

[0002] In a large logistics hub, operations management often relies on logistics twin scenarios built using computer-aided design software. These scenarios typically employ a hierarchical data structure, where basic physical units are represented as component-level dynamic blocks, encapsulating technical specifications. Multiple component-level dynamic blocks combine to form functionally complete device-level dynamic blocks, and multiple device-level dynamic blocks further combine to form higher-level functional area dynamic blocks. This hierarchical structure allows personnel in different roles to view information at different granularities as needed.

[0003] However, existing data analysis systems have shortcomings in handling such hierarchical data structures. When a core performance parameter of a low-level, nested component-level dynamic block is modified, existing analysis systems often employ pre-defined, fixed calculation logic when performing data aggregation and calculating performance indicators of upper-level devices. This fixed logic fails to fully understand and utilize the pre-established functional role binding relationships between components and their parent devices, as well as the specific physical constraints inherent therein. For example, for a device-level dynamic block (such as a linear conveyor belt), the calculation of its key performance indicators (such as maximum conveying speed) may only rely on the parameters of certain internal components (such as rollers), while ignoring the decisive impact of parameter changes in other key components (such as drive motors) on overall performance.

[0004] Therefore, even if the key performance parameters of the underlying components have changed, the performance indicators of upper-level devices calculated by the existing system may still be based on old or irrelevant parameters, leading to calculation results that do not match reality. This distortion of underlying data will propagate upwards, affecting the accuracy of performance evaluation and prediction for higher-level functional areas and even the entire system. Incorrect performance evaluation may lead to operational decision-making errors, such as allocating excessive workloads when actual capabilities are insufficient, ultimately causing operational disruptions or inefficiencies. Summary of the Invention

[0005] The purpose of this application is to provide a data analysis method and system for a modular logistics system, which has the advantages of accurately reflecting the impact of changes in the parameters of the underlying components on the performance of the upper-level equipment and improving the accuracy of data analysis.

[0006] On the one hand, this application provides a modular logistics system data analysis method, including:

[0007] Create a device function template, which contains multiple component role slots, each slot specifying the type of component to be received and key input / output parameters;

[0008] The device function template encapsulates a logic relationship script, which defines the operational relationships between parameters of each component role slot.

[0009] A device instance is created based on the device function template, and at least one component instance is bound to the component role slot contained in the device function template associated with the device instance. The component instance is a functional constituent unit of the device instance, and the performance parameters of the component instance participate in the calculation of device performance indicators through the logical relationship script bound to the device instance.

[0010] In response to the modification of the performance parameters of the first component instance, the logical relationship script is invoked to recalculate the device performance metrics, and the calculation result is updated to the performance metrics of the device instance, wherein the first component instance is one of the component instances in the device instance.

[0011] Optionally, the step of calling the logical relationship script to recalculate the device performance metrics in response to a modification of the performance parameters of the first component instance, and updating the calculation result to the performance metrics of the device instance, includes:

[0012] In response to a modification of the performance parameters of the first component instance, detect the first component role slot bound to the first component instance;

[0013] The device performance metrics are recalculated by calling the corresponding logical relationship script based on the first component role slot, and the calculation result is updated as the performance metrics of the device instance.

[0014] Optionally, the step of calling the logical relationship script to recalculate the device performance metrics in response to a modification of the performance parameters of the first component instance, and updating the calculation result to the performance metrics of the device instance, includes:

[0015] An early warning sensing area is set upstream of the device instance to obtain early warning information carrying the identity information of the logistics object before the logistics object arrives at the device instance;

[0016] In response to the warning information, based on the modified performance parameters and the identity information of the logistics object, the logical relationship script is invoked to perform pre-calculation, and the first device performance index bound to the logistics object is obtained and cached.

[0017] In response to a data query request issued for the logistics object, the first device performance index is extracted from the cache, and the performance index of the device instance is updated using the first device performance index.

[0018] Optionally, the step of responding to the warning information by calling the logical relationship script to perform pre-calculation based on the modified performance parameters and the identity information of the logistics object, and obtaining and caching the first equipment performance index bound to the logistics object, includes:

[0019] In response to the warning information, a pre-calculated task associated with the identity information of the logistics object is generated;

[0020] Based on the identity information of the logistics object, query the business priority associated with the logistics object;

[0021] The pre-computation task is bound to the business priority and placed into a computation task queue;

[0022] The computing module schedules multiple pre-computation tasks in the computing task queue according to the business priority, and extracts the pre-computation tasks to be executed from the computing task queue.

[0023] For the pre-calculation task to be executed, the logical relationship script is invoked to perform pre-calculation based on the modified performance parameters and the identity information of the logistics object, so as to obtain and cache the first equipment performance index bound to the logistics object.

[0024] Optionally, the step of scheduling multiple pre-computation tasks in the computation task queue according to the service priority by the computation module, and extracting pre-computation tasks to be executed from the computation task queue includes:

[0025] Monitor changes in the business attributes of logistics objects associated with pre-computation tasks already placed in the computation task queue, in order to obtain business attribute change information including the identity information of the logistics object and the new business priority;

[0026] In response to the business attribute change information, the corresponding pre-calculation task is retrieved from the calculation task queue based on the logistics object identity information;

[0027] Update the processing priority bound to the first pre-calculation task according to the new business priority indicated by the business attribute change information;

[0028] The computing module schedules multiple pre-computation tasks in the computing task queue according to the updated processing priority, and extracts pre-computation tasks to be executed from the computing task queue.

[0029] Optionally, the step of scheduling multiple pre-computation tasks in the computation task queue according to the updated processing priority by the computation module, and extracting pre-computation tasks to be executed from the computation task queue includes:

[0030] Configure resource consumption attributes that characterize the computational load for each pre-computation task in the computation task queue;

[0031] Obtain the real-time load status of the computing module;

[0032] The computing module selects pre-computation tasks to be checked from the computing task queue according to the processing priority;

[0033] The resource consumption attributes of the pre-computation task to be checked are compared with the real-time load status of the computing module to generate a comparison result.

[0034] When the comparison result indicates that the real-time load status of the computing module meets the resource consumption attribute, the pre-computation task to be checked is extracted from the computing task queue as a pre-computation task to be executed.

[0035] Optionally, the step of scheduling multiple pre-computation tasks in the computation task queue according to the updated processing priority by the computation module, and extracting pre-computation tasks to be executed from the computation task queue includes:

[0036] When the comparison result shows that the real-time load status of the computing module does not meet the resource consumption attributes of the pre-computation task to be checked, a priority check identifier is set for the pre-computation task to be checked.

[0037] After the real-time load status of the computing module changes, check in the computing task queue whether there is a pre-computation task with the priority check flag set.

[0038] If there is a pre-computation task with the priority check flag, the resource consumption attribute of the pre-computation task with the priority check flag is compared with the real-time load status of the changed computing module to generate a new comparison result; when the new comparison result shows that the real-time load status of the changed computing module meets its resource consumption attribute, the pre-computation task with the priority check flag is extracted as a pre-computation task to be executed.

[0039] If there is no pre-computation task with the priority check flag set, or if the new comparison result shows that the real-time load status of the changed computing module still does not meet its resource consumption attributes, then other pre-computation tasks are selected from the computing task queue as pre-computation tasks to be checked according to the processing priority.

[0040] Optionally, the step of extracting the pre-computation task to be checked from the computation task queue as a pre-computation task to be executed when the comparison result shows that the real-time load status of the computing module meets the resource consumption attribute includes:

[0041] Determine if there are multiple pre-computed tasks to be inspected that have the same highest business priority;

[0042] If it is determined that there are multiple pre-calculation tasks to be inspected with the same highest business priority, then the multiple pre-calculation tasks to be inspected with the same highest business priority are determined as a task group to be selected.

[0043] For each pre-computed task in the task group to be selected, obtain the current running state of the device instance associated with the pre-computed task, and the target running state required to execute the pre-computed task;

[0044] Based on the current running state and the target running state, determine the state switching cost corresponding to each pre-calculated task in the task group to be selected;

[0045] Based on the state switching cost, select a pre-computed task from the group of tasks to be selected as the pre-computed task to be executed;

[0046] Extract the pre-computation task to be executed from the computation task queue;

[0047] If it is determined that there are no multiple pre-computation tasks to be inspected with the same highest business priority, then the pre-computation task to be inspected is taken as a pre-computation task to be executed, and the pre-computation task to be executed is extracted from the computation task queue.

[0048] Optionally, the step of determining the state switching cost corresponding to each pre-calculated task in the task group to be selected based on the current running state and the target running state includes:

[0049] Obtain dynamic factor data that affects the cost of the state transition;

[0050] The dynamic factor data is combined with the current operating state and the target operating state to obtain the basis for determining the state switching cost;

[0051] Based on the criteria used to determine the state switching cost, the state switching cost corresponding to each pre-calculated task in the task group to be selected is determined.

[0052] On the other hand, this application provides a modular logistics system data analysis system, which includes:

[0053] The template creation module is used to create device function templates. The device function template contains multiple component role slots, and each slot specifies the type of component to be received and the key input and output parameters.

[0054] The script encapsulation module encapsulates the logical relationship script in the device function template, wherein the logical relationship script defines the operation relationship of parameters between the slots of each component role;

[0055] The instance management module is used to create device instances based on the device function template and bind at least one component instance to the component role slots contained in the device function template associated with the device instance. The component instance is a functional constituent unit of the device instance, and the performance parameters of the component instance participate in the calculation of device performance indicators through the logical relationship script bound to the device instance.

[0056] The performance update module is used to respond to the modification of the performance parameters of the first component instance by calling the logical relationship script to recalculate the device performance index and updating the calculation result to the performance index of the device instance, wherein the first component instance is one of the component instances in the device instance.

[0057] This application provides a modular logistics system data analysis method and system. By constructing modular equipment function templates, encapsulating logical relationship scripts, and dynamically responding to component parameter changes for calculation, it solves the problem in the prior art that changes in underlying parameters cannot be accurately transmitted to the performance indicators of upper-level equipment. It has the advantage of being able to accurately reflect the impact of changes in underlying component parameters on the performance of upper-level equipment and improving the accuracy of data analysis. Attached Figure Description

[0058] To more clearly illustrate the technical solution of this application, the drawings used in the embodiments will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0059] Figure 1 The diagram above illustrates a data analysis method for a modular logistics system in an embodiment.

[0060] Figure 2 The diagram illustrates a modular configuration block diagram of a data analysis system for a modular logistics system in an embodiment.

[0061] Attached reference numerals: 100, Modular logistics system data analysis system; 10, Template creation module; 20, Script encapsulation module; 30, Instance management module; 40, Performance update module. Detailed Implementation

[0062] The technical solutions of this application will now be clearly and completely described with reference to the accompanying drawings. Obviously, the described embodiments are merely some embodiments of this application, and not all embodiments. The components of this application described and shown in the accompanying drawings can generally be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of this application provided in the accompanying drawings is not intended to limit the scope of the claimed application, but merely to illustrate selected embodiments of this application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without inventive effort are within the scope of protection of this application.

[0063] It should be noted that similar reference numerals and letters in the following figures indicate similar items; therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures. Furthermore, in the description of this application, terms such as "first," "second," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0064] Traditional logistics twin scenarios built using computer-aided design software, when representing the physical system with a fixed hierarchical nested structure, suffer from data aggregation issues when the performance parameters of the underlying component-level dynamic blocks change. This is because existing data analysis systems use pre-defined, fixed computational logic to aggregate data, failing to correctly understand and transmit the non-linear, bottleneck-like impact of the parameter changes of the underlying components on the functions of the upper-level equipment. Consequently, the parameter changes of the underlying components cannot be accurately converted and updated to the key performance indicators of their parent equipment blocks, resulting in distorted cross-level data transmission and limiting the predictive analysis capabilities of the twin scenario.

[0065] For example, suppose a linear conveyor belt unit in a logistics hub's twin scenario consists of multiple roller assembly blocks and a motor assembly block. The key performance indicator ("maximum conveying speed") of the linear conveyor belt unit in the existing system is calculated by arithmetically averaging the "design linear speed" parameters of all roller assembly blocks. When the user replaces the motor assembly block of this linear conveyor belt with a new motor and updates the "rated speed" parameter of the motor assembly block, because the "design linear speed" parameter of the roller assembly blocks remains unchanged, the existing analysis system will still use the old calculation logic, calculating an incorrect "maximum conveying speed" indicator for the linear conveyor belt unit based on the unchanged roller parameters. This incorrect data will propagate to the dynamic blocks of higher-level functional areas, affecting the calculation of higher-level indicators, such as the functional area's "peak processing capacity," ultimately leading to operational decisions based on the twin scenario that do not match the actual operating state of the physical system.

[0066] If the aforementioned issues are not addressed, the twin scenario based on distorted data will fail to accurately reflect the true operational capabilities and status of the physical system. This will lead to operational decisions based on erroneous information, such as assigning tasks beyond actual processing capacity during peak business periods, resulting in a series of operational incidents such as system bottlenecks, process interruptions, package backlogs, and order delays. Simultaneously, troubleshooting and system optimization will become difficult and time-consuming because the twin scenario cannot provide accurate performance data to pinpoint the root cause of problems or assess the effectiveness of optimizations, severely impacting the overall efficiency and reliability of the logistics system.

[0067] Faced with the aforementioned problems, this application initially considered modifying the aggregation algorithm of the existing analysis system to consider the impact of component parameters on equipment performance. However, this approach requires writing specific calculation logic for each equipment type and each combination of component parameter changes, resulting in a huge workload and difficulty in maintenance, especially given the diverse types of equipment and flexible component configurations in logistics systems. Therefore, this application further explores the possibility of constructing a more general and flexible method that allows the performance correlation and calculation logic between equipment and components to be defined and managed in a modular and scripted manner. By creating reusable functional templates for different types of equipment and encapsulating scripts describing the logical relationships between component parameters and equipment performance within these templates, the system can automatically invoke the corresponding scripts for accurate calculations when component parameters change, thereby dynamically updating equipment performance indicators and ensuring accurate data transmission between levels.

[0068] like Figure 1 As shown, an exemplary data analysis and optimization method for a modular logistics system is illustrated. The modular logistics system data analysis method proposed in this application includes:

[0069] S10, Create a device function template. The device function template contains multiple component role slots. Each slot specifies the type of component to be received and the key input and output parameters.

[0070] S20, encapsulate the logical relationship script in the device function template, wherein the logical relationship script defines the operation relationship of parameters between the slots of each component role;

[0071] S30, create a device instance based on the device function template, and bind at least one component instance to the component role slot contained in the device function template associated with the device instance. The component instance is the functional unit of the device instance, and the performance parameters of the component instance participate in the calculation of device performance indicators through the logical relationship script bound to the device instance.

[0072] S40, in response to the modification of the performance parameters of the first component instance, the logical relationship script is called to calculate the updated device performance index, and the performance index of the device instance is updated with the updated device performance index, wherein the first component instance is any component instance in the device instance.

[0073] Among them, the device function template refers to an abstract model used to define the functional structure and behavioral logic of a class of devices. It is implemented using data structures, configuration files or specific modeling languages, such as XML files, JSON objects or database records. Its main purpose is to provide a blueprint for creating specific device instances.

[0074] Component role slots refer to interfaces reserved in the device function template to specify the required component types and their input and output parameters. They are implemented using data fields, attribute definitions, or interface specifications, such as specific fields or interface definitions in the template. They are mainly used to specify the requirements of the device function constituent units.

[0075] Logical relationship scripts refer to program code encapsulated in device function templates that describes the parameter operation relationships between component role slots. They can be implemented using scripting languages, executable functions, or calculation expressions, such as Python scripts, JavaScript functions, or mathematical formulas. They are mainly used to define the calculation rules for device performance indicators.

[0076] A device instance is an entity object created based on a device function template, representing a specific piece of equipment in a logistics system. It is the instantiation result of the template from abstraction to concreteness, corresponding to a specific piece of equipment actually running in the logistics system, such as a straight conveyor belt or a curved conveyor belt. The creation of a device instance must be based on a predefined device function template, which specifies the functional structure of the equipment (such as which component roles are required), interface specifications (input and output parameters), and logical relationships (how parameters are calculated between components).

[0077] A component instance is a functional unit of a device instance, and a concrete implementation of the component role slot in the device function template. It corresponds to a physical or logical module within the device that can operate independently and possesses specific functions, such as a motor assembly, roller assembly, or sensor assembly that makes up a linear conveyor belt. Each component instance has its own "performance parameters" (such as the sensor's sampling frequency and the motor's rotational speed). These parameters participate in the calculation of the overall device performance indicators through the device instance's logical relationship script (for example, the sensor's sampling frequency affects sorting accuracy, and the motor's rotational speed affects sorting speed). In this application, in response to a modification to the performance parameters of the first component instance, the logical relationship script is invoked to calculate the updated device performance indicators, and the updated device performance indicators are then used to update the device instance's performance indicators.

[0078] In some embodiments, the first component instance is any component instance in the device instance. The first component role slot bound to the first component instance refers to an interface or position preset in the device function template for receiving a specific type of component instance and defining its role in the device.

[0079] In general, a device instance is the "whole," while a component instance is a "part." The device function template defines which parts are needed for the whole, that is, the component roles, and how these component roles collaborate through logic scripts. The device instance and component instance are the concrete entities that implement the template. By adjusting the parameters of the component instances (such as replacing sensors or upgrading motors), combined with the dynamic calculations of the logic scripts, flexible optimization and real-time monitoring of device performance can be achieved.

[0080] In some embodiments, an association is established between a component instance and a component role slot in the device function template of a device instance. This can be achieved by pointer reference, ID association, or data mapping. For example, a reference to the component instance is stored in the device instance object, or an association table is established in the database. This is mainly used to connect specific component functional units to the device structure.

[0081] In some embodiments, the performance metrics of a device instance (such as sorting efficiency and failure rate) are dynamically calculated by combining the bound component instance parameters with the logical relationship script.

[0082] The core innovation of this application lies in the fact that by combining device function templates, component role slots and logical relationship scripts, a dynamic calculation relationship between component instance parameters and device instance performance indicators is established, so as to achieve the effect that changes in the underlying component parameters can be accurately transmitted to the upper-level device performance indicators.

[0083] This application defines the functional structure and parameter interfaces of a device by creating a device function template, and encapsulates logical relationship scripts within the template, clarifying how component parameters affect device performance. Based on this template, device instances are created, and specific component instances are bound to template slots of the device instances. This allows the performance parameters of the component instances to participate in the calculation of device performance metrics through the bound logical relationship scripts. When the performance parameters of the first component instance are modified, the system can call the logical relationship script associated with that device instance, and recalculate the updated device performance metrics using the updated component parameters according to the operational relationships defined in the script. Subsequently, the updated device performance metrics are used to update the device instance's own performance metrics. The reason for achieving accurate data transmission is that the logical relationship script can capture the real physical or functional constraints between components and the device, rather than relying on fixed, generic aggregation algorithms. It is precisely this dynamic, relationship-based calculation mechanism that allows changes in the parameters of the underlying components to be accurately reflected in the performance of the upper-layer device, solving the problem of data transmission distortion in traditional methods.

[0084] The above technical solution establishes a dynamic correlation mechanism for parameter transfer and performance calculation between equipment and its constituent components in a logistics system. When the performance parameters of the underlying components change, it automatically triggers the recalculation and updating of the performance indicators of the upper-level equipment. This ensures that, within the hierarchical data structure, changes in the underlying data are accurately and in real-time reflected in the aggregated indicators at the upper level. This solves the data transmission distortion problem caused by fixed calculation logic in existing technologies, improves the authenticity and reliability of data analysis in logistics twin scenarios, and provides an accurate data foundation for operational decision-making and predictive analysis based on the twin scenario.

[0085] In some embodiments, in response to a modification of the performance parameters of a first component instance, the step of calling a logical relationship script corresponding to the device instance to calculate the updated device performance metrics, and updating the performance metrics of the device instance using the updated device performance metrics, includes:

[0086] In response to a modification to the performance parameters of the first component instance, detect the first component role slot bound to the first component instance;

[0087] Based on the role slot of the first component, the corresponding logical relationship script is called to perform targeted calculations to obtain the updated device performance indicators;

[0088] Update the performance metrics of the device instance with the updated device performance metrics.

[0089] In response to modifications to the performance parameters of the first component instance, the system first detects the first component role slot bound to that first component instance. Because the component instance is bound to the component role slot in the device function template, and the logical relationship script defines the operational relationships based on these slot parameters, the system can determine the scope and type of the impact of parameter changes by detecting the specific slot bound to the component instance whose parameters have been modified.

[0090] Based on this, according to the detected first component role slot, the corresponding logical relationship script is invoked for targeted calculation to obtain the updated device performance indicators. This means that the system no longer executes the entire logical relationship script, but instead locates and executes the calculation logic related to that slot in the script based on the slot information. This targeted calculation avoids unnecessary computation and improves processing efficiency. Finally, the updated device performance indicators are used to update the performance indicators of the device instance. Through the above steps, the solution of this application can accurately identify the sources of influence of parameter changes and perform targeted calculations, ensuring that the update of device performance indicators is both efficient and accurate, overcoming the problems of excessive calculation scope, low efficiency, and inaccurate updates in the prior art.

[0091] For example, consider a linear conveyor belt device instance whose device function template includes a drive component role slot and a carrier component role slot. One motor component instance is bound to the drive slot, and multiple roller component instances are bound to the carrier slots. The logic relationship script defines how the maximum conveyor speed of the conveyor belt is calculated from parameters such as the rated speed of the drive motor and the diameter of the carrier rollers. When the user modifies the rated speed parameter of the motor component instance, the system responds to this modification by first detecting that the motor component instance is bound to the "drive" component role slot. Next, based on the information from the "drive" slot, the system calls the corresponding logic relationship script in the linear conveyor belt device function template to perform directional calculations. Specifically, the script executes calculation logic related to the "drive" slot, such as calculating a new maximum conveyor speed based on the modified rated motor speed and roller diameter. Finally, the system uses the calculated updated maximum conveyor speed value to update the performance metrics of the linear conveyor belt device instance.

[0092] Through the above technical solution, in response to modifications to the performance parameters of the first component instance, the scope of the impact of the parameter modification can be clearly defined by detecting the first component role slot bound to the first component instance, avoiding unnecessary global calculations. By calling the corresponding logical relationship script for targeted calculation based on the first component role slot, it can be ensured that the calculation logic and the component instance's role in the device are precisely matched, achieving accurate calculation. The updated device performance metrics are then used to update the device instance's performance metrics, completing the update of the device performance metrics. Therefore, this application can achieve accurate and efficient updates of device performance metrics, improving the efficiency and accuracy of data analysis.

[0093] This application further proposes a method for responding to modifications to the performance parameters of a first component instance, involving calling a logical relationship script to calculate updated device performance metrics, and then updating the performance metrics of the device instance using the updated device performance metrics. The steps include:

[0094] An early warning sensing area is set up upstream of the device instance to obtain early warning information carrying the identity information of the logistics object before the logistics object arrives at the device instance.

[0095] In response to the warning information, based on the modified performance parameters and the identity information of the logistics object, the logical relationship script is invoked to perform pre-calculation, obtain and cache the first equipment performance index bound to the logistics object;

[0096] In response to a data query request issued for a logistics object, the first device performance metric is extracted from the cache, and the performance metric of the device instance is updated using the first device performance metric.

[0097] The early warning sensing area refers to the sensing unit set up upstream of the physical location of the equipment instance. Specifically, it can be various sensors, identification devices or data interfaces. Its purpose is to detect the logistics objects that are about to arrive in advance and obtain their key information.

[0098] Early warning information refers to data signals containing the identity information of logistics objects obtained by the early warning sensing area. Specifically, it can be information such as package ID and type obtained by scanning barcodes, reading RFID tags or image recognition. Its purpose is to identify specific logistics objects so that they can be processed in a personalized manner.

[0099] Before the logistics object actually arrives at the equipment instance, the logical relationship script is called in advance to calculate the performance indicators based on the currently known parameters (such as the modified performance parameters and the logistics object's identity information) and obtain the predicted equipment performance value when the logistics object arrives.

[0100] A data query request refers to a request issued by the system or other modules to obtain the performance indicators of a specific logistics object on a device instance. Specifically, it can be triggered by a monitoring system, a scheduling system, or a user interface, with the purpose of obtaining the latest device performance data related to the logistics object.

[0101] This application establishes a warning sensing area upstream of the device instance, enabling the system to detect the existence of a logistics object and obtain its identity information before its actual arrival, thereby triggering a pre-calculation process. The pre-calculation utilizes modified performance parameters and the logistics object's identity information to call a logical relationship script to pre-calculate the performance indicators of the logistics object as it passes through the device instance, and caches the results. When subsequent data query requests for this logistics object arise, the system can directly retrieve the pre-calculated results from the cache without performing real-time calculations. This warning, pre-calculation, and caching mechanism allows the system to predict changes in device performance indicators in advance and quickly provide accurate data when needed, effectively solving the latency problem that real-time calculations may cause in high-concurrency scenarios and providing a data foundation for advance resource allocation and optimization. Combined with the basic solution, this approach retains the ability to reflect component parameter changes in device performance in real time while further improving the system's response speed and predictive capabilities under high loads, thus enhancing the overall efficiency and intelligence level of the logistics system.

[0102] For example, taking a conveyor belt system as an example, a photoelectric sensor can be set up at its entrance as a warning sensing area. When a package passes through the photoelectric sensor, the sensor acquires the package's barcode information as a warning. In response to this warning, the system, based on the known modified performance parameters of components such as the conveyor belt drive motor (e.g., reduced motor rated speed) and the package's identification information (barcode), calls a logic script bound to the conveyor belt system instance (e.g., a script to calculate package transit time) to perform pre-calculation, predicting the time required for the specific package to pass through the conveyor belt. This predicted time is then used as the first equipment performance indicator, bound to the package's barcode, and cached. When the logistics scheduling system needs to query the estimated time for the package to pass through the conveyor belt, it issues a data query request. The system directly retrieves the predicted time associated with the package's barcode from the cache and updates the conveyor belt system instance's performance indicator record for that package with this predicted time.

[0103] Through the above technical solution, the system can calculate and cache the relevant equipment performance indicators of logistics objects before they arrive at the equipment instance, avoiding the delays that may occur when performing real-time calculations upon arrival, and significantly improving the response speed of data queries. At the same time, the performance indicators obtained in advance facilitate earlier resource planning and scheduling decisions, improving the operational efficiency and predictive capabilities of the logistics system.

[0104] In some embodiments, this application further proposes a step of responding to a warning message by invoking a logical relationship script to perform pre-calculation based on the modified performance parameters and the identity information of the logistics object, and obtaining and caching the first equipment performance index bound to the logistics object, including:

[0105] In response to the warning information, a pre-calculated task associated with the identity information of the logistics object is generated;

[0106] Based on the identity information of the logistics object, query the business priority associated with the logistics object;

[0107] The pre-computation task is bound to the business priority and placed into a computation task queue;

[0108] The computing module schedules multiple pre-computation tasks in the computing task queue according to the business priority, and extracts the pre-computation tasks to be executed from the computing task queue.

[0109] For the pre-calculation task to be executed, the logical relationship script is invoked to perform pre-calculation based on the modified performance parameters and the identity information of the logistics object, so as to obtain and cache the first equipment performance index bound to the logistics object.

[0110] Among them, the pre-computation task refers to a data processing unit created for a specific logistics object before it arrives at the equipment instance, based on its identity information and changes in equipment performance parameters. It needs to execute a logical relationship script to calculate its equipment performance indicators. It can be implemented using a software object containing data structures such as task identifier, logistics object identity information, relevant performance parameter references, and logical script references. Its purpose is to structure and manage the pre-computation requirements.

[0111] Logistics object identity information refers to attribute data used to uniquely identify a logistics object, such as the tracking number, order number, or internal identification code of a package. It can be implemented using strings, number sequences, or composite data structures containing multiple attributes. Its purpose is to associate pre-calculated tasks with specific logistics objects.

[0112] Business priority refers to the attribute that characterizes the importance or processing order of logistics objects in the entire logistics process. It can be implemented using integer values, enumeration types, or predefined priority labels, and its purpose is to provide a basis for scheduling computational tasks.

[0113] A computation task queue is a data structure used to store pre-computation tasks to be processed. It can be implemented using data structures such as lists, heaps, or priority queues. Its purpose is to centrally manage and sort pre-computation tasks.

[0114] A computing module is a hardware or software unit responsible for performing pre-computation tasks. It can be implemented using servers, computing clusters, or dedicated processing chips. Its purpose is to provide computing power and execute scheduling logic.

[0115] By employing priority-based sorting algorithms or more complex scheduling strategies, the next task to be executed from the computing task queue can be selected according to business priority, thereby optimizing the allocation of computing resources and the processing order of tasks.

[0116] By introducing pre-computation tasks, business priorities, a computational task queue, and a priority-based scheduling mechanism, the pre-computation process is transformed from a simple trigger-based execution into an ordered and controllable task processing flow. Specifically, when an alert is triggered, the system no longer immediately attempts to execute calculations. Instead, it first generates a structured pre-computation task for the logistics object and queries the corresponding business priority of that object. Subsequently, the task is bound to its priority and placed into a computational task queue. The computation module continuously monitors this queue and dynamically selects and extracts the highest-priority task for processing based on the business priority bound to the task. It is precisely this priority-based task management and scheduling mechanism that enables the system to distinguish the importance of different logistics objects, ensuring that pre-computation tasks for high-value or urgent logistics objects receive priority access to computing resources and are executed, avoiding the blocking of high-priority tasks by low-priority tasks. Compared to the simple trigger-based calculation method in previous solutions, this approach significantly improves the efficiency and response speed of pre-computation, especially in scenarios where a large number of logistics objects arrive at the alert area simultaneously. It effectively manages the computational load, optimizes resource allocation, and thus ensures the smooth operation of critical logistics business.

[0117] For example, in a logistics sorting center, when a package containing important goods is about to enter the warning area of ​​a linear conveyor belt (equipment instance), the warning sensor acquires the package's identification information and generates a warning message. Upon receiving the warning message, the system immediately generates a pre-computation task associated with the package's identification information. The system queries the package's priority in the business system based on its identification information; for example, if the package is marked as "urgent," it corresponds to a higher business priority. The system binds the pre-computation task to the "urgent" business priority and places it in a computation task queue. The computation module continuously checks the task queue; if multiple tasks exist in the queue, the computation module prioritizes the task with the highest business priority for processing. Assuming the "urgent" task is currently the highest priority in the queue, the computation module extracts it as the pre-computation task to be executed. Subsequently, for the task to be executed, the calculation module calls the logical relationship script associated with the sorting equipment, combines the modified performance parameters of a component of the sorting equipment (e.g., drive motor) and the identity information of the package (e.g., package weight, size), performs pre-calculation to obtain the first equipment performance indicators such as the expected processing time or energy consumption when the package passes through the sorting equipment, and caches this calculation result after binding it with the package for use in subsequent sorting decisions.

[0118] The above technical solution transforms the pre-computation process into a scheduling process based on task queues and business priorities. This ensures that pre-computation tasks for high-priority logistics objects are processed first, improving the efficiency and timeliness of pre-computation. Simultaneously, the unified scheduling of task queues by the computing module enables the rational allocation of computing resources, avoiding resource waste or congestion, and enhancing the logistics system's responsiveness to logistics objects of varying importance and its overall operational efficiency.

[0119] This application further proposes a step in which the computing module schedules multiple pre-computation tasks in the computing task queue according to business priority, including:

[0120] Monitor changes in the business attributes of logistics objects associated with pre-computation tasks already placed in the computation task queue, in order to obtain business attribute change information including the identity information of the logistics object and the new business priority;

[0121] In response to changes in business attributes, the corresponding pre-calculated tasks are retrieved from the task queue based on the identity information of the logistics object.

[0122] Update the processing priority bound to the first pre-calculation task according to the new business priority indicated by the business attribute change information;

[0123] The computing module schedules multiple pre-computation tasks in the computing task queue according to the updated processing priority, and extracts the pre-computation tasks to be executed from the computing task queue.

[0124] Among them, changes in business attributes refer to changes in non-physical attributes related to logistics objects, such as service level, destination, customer requirements, etc., and timely detection of changes in external factors that affect task priority.

[0125] Business attribute change information refers to structured data that records the specific content of business attribute changes, including the identity information of logistics objects and the new business priority after the change. It can take the form of messages in message queues, change records in databases, specific data packets, etc. Its purpose is to provide the core information required for priority updates.

[0126] New business priority refers to the new processing priority corresponding to the change of business attributes of logistics objects. It can be represented by numerical values, enumeration values, positions in priority queues, etc. Its purpose is to reflect the requirements of the latest business needs of logistics objects on the processing order of calculation tasks.

[0127] In some embodiments, by monitoring changes in the business attributes of logistics objects associated with pre-computation tasks already placed in the computation task queue, business attribute change information containing the identity information of the logistics object and the new business priority is obtained in a timely manner. In response to this information, the corresponding pre-computation task is retrieved in the computation task queue based on the identity information of the logistics object. Then, according to the new business priority indicated by the business attribute change information, the processing priority bound to the retrieved first pre-computation task is updated. Finally, the computation module schedules multiple pre-computation tasks in the computation task queue according to the updated processing priority and extracts the pre-computation tasks to be executed from the computation task queue.

[0128] This enables the system to dynamically adjust the processing order of pre-computed tasks in the queue, overcoming the limitations of the original static scheduling based on initial priority. By introducing dynamic monitoring of the business attributes of logistics objects and a real-time update mechanism for the priority of queued tasks, this application can flexibly adapt to changes in business needs that may occur during the logistics process, ensuring that computing resources always prioritize the most urgent and important tasks. This dynamic adjustment capability, combined with the mechanism of triggering task generation based on early warnings and binding initial priorities, forms a scheduling system that can both quickly respond to events and flexibly adapt to changes. This significantly improves the response speed and accuracy of the entire logistics data analysis and processing, especially when dealing with high-priority or temporarily urgent logistics objects, effectively avoiding process bottlenecks and inefficiencies caused by incorrect priorities.

[0129] For example, when a package (logistics object) enters the sorting area (early warning sensor area), the system generates a pre-calculated task for it (e.g., calculating the optimal sorting route) and places it in the calculation task queue based on its initial business priority. While the task is still waiting for processing in the queue, if the package's business attributes change, for example, if a customer upgrades the package's service level to expedited through the customer service system, the system will detect this business attribute change and obtain business attribute change information including the package ID and the new business priority of expedited. In response to this information, the system retrieves the corresponding pre-calculated task in the calculation task queue based on the package ID. Subsequently, the system updates the processing priority bound to the first retrieved pre-calculated task according to the new business priority expedited indicated by the business attribute change information. During subsequent scheduling, the calculation module will select tasks based on the updated processing priority expedited. Because the expedited priority is higher than the standard priority, this task will be extracted and executed first.

[0130] The above technical solution resolves the issue of pre-calculated task priorities becoming invalid due to changes in the business attributes of logistics objects. By dynamically monitoring and updating priorities, it ensures that the scheduling of pre-calculated tasks reflects the latest business needs of logistics objects in real time. This allows high-priority tasks to be processed promptly, avoiding delays and resource waste caused by incorrect priorities. It also improves the efficiency of logistics data analysis and processing, guarantees the quality of logistics services, and better addresses unexpected changes in business demands.

[0131] In some embodiments, this application further proposes a step in which the computing module schedules multiple pre-computation tasks in the computing task queue according to the updated processing priority, and extracts the pre-computation tasks to be executed from the computing task queue, including:

[0132] Configure resource consumption attributes that characterize the computational load for each pre-computation task in the computation task queue;

[0133] Obtain the real-time load status of the computing module;

[0134] The computing module selects pre-computation tasks to be checked from the computing task queue based on processing priority;

[0135] The resource consumption attributes of the pre-computation task to be checked are compared with the real-time load status of the computing module to generate comparison results.

[0136] When the comparison results show that the real-time load status of the computing module meets the resource consumption attributes, the pre-computation tasks to be checked are extracted from the computing task queue as pre-computation tasks to be executed.

[0137] Among them, resource consumption attributes refer to a set of indicators used to quantify the degree of computing resource demand of pre-computation tasks during execution. These can be represented by one or more indicators, including CPU utilization, memory usage, disk IOPS, and network bandwidth requirements. Their purpose is to provide a basis for resource demand in task scheduling.

[0138] The real-time load status of a computing module refers to its resource usage and workload at a given moment. It can be represented by one or more metrics, including CPU utilization, memory utilization, disk I / O queue length, and network traffic, reflecting the module's current resource supply capacity. Processing priority refers to the order in which pre-computation tasks are executed within the computing task queue. It can be represented by numerical values, levels, or labels, ensuring that high-priority tasks receive priority scheduling checks.

[0139] Pre-computation tasks to be checked refer to pre-computation tasks selected from the computation task queue according to processing priority during a scheduling cycle, which are prepared for resource feasibility checks.

[0140] By configuring resource consumption attributes for each pre-computation task and acquiring the load status of the computing module in real time, after selecting tasks to be checked based on processing priority, the resource requirements of the task are further compared with the resource supply of the module. Only when the comparison result shows that the module load status meets the resource consumption attributes of the task is the task extracted as a task to be executed. It is precisely because of the addition of a judgment step on the resource carrying capacity of the computing module on the basis of task scheduling based on business priority that the system can prioritize the processing of high-priority tasks while avoiding the allocation of tasks with resource requirements exceeding the current supply capacity to the computing module, thereby effectively preventing the computing module from being overloaded. This scheduling mechanism that combines business priority and resource load makes the execution of pre-computation tasks more efficient and stable, ensuring the timeliness and accuracy of logistics system data analysis.

[0141] For example, a pre-computation task is configured with resource consumption attributes, such as requiring 2 CPU cores and 4GB of memory. The system monitors the load status of the computing module in real time, for example, the current CPU utilization is 60% and the available memory is 10GB. The scheduler selects this pre-computation task as a task to be checked based on processing priority. The system compares the resource consumption attributes of this task (2 CPU cores, 4GB of memory) with the real-time load status (available resources) of the computing module. If the computing module currently has at least 2 idle CPU cores and at least 4GB of available memory, the comparison result shows that the load status meets the resource consumption attributes, and the pre-computation task will be extracted for execution. Conversely, if the computing module currently has only 1 idle CPU core or less than 4GB of available memory, the comparison result shows that the load status does not meet the requirements, and the task will not be extracted for execution for the time being.

[0142] The above technical solution, based on task scheduling according to business priority, further considers the resource load of the computing module. By comparing the resource requirements of the task with the real-time resource supply of the module, the task to be executed is extracted conditionally, thereby avoiding overload of the computing module due to processing tasks with excessively high resource requirements, and improving computing efficiency and system stability.

[0143] Furthermore, this application proposes a step in which the computing module schedules multiple pre-computation tasks in the computing task queue according to the updated processing priority, and extracts the pre-computation tasks to be executed from the computing task queue, including:

[0144] When the comparison results show that the real-time load status of the computing module does not meet the resource consumption attributes of the pre-computation task to be checked, a priority check flag is set for the pre-computation task to be checked.

[0145] After the real-time load status of the computing module changes, check in the computing task queue whether there are any pre-computation tasks with priority check flags set.

[0146] If there is a pre-computation task with a priority check flag, the resource consumption attribute of the pre-computation task with the priority check flag is compared with the real-time load status of the changed computing module to generate a new comparison result. When the new comparison result shows that the real-time load status of the changed computing module meets its resource consumption attribute, the pre-computation task with the priority check flag is extracted as a pre-computation task to be executed.

[0147] If there is no pre-computation task with a priority check flag, or if the new comparison results show that the real-time load status of the changed computing module still does not meet its resource consumption attributes, then other pre-computation tasks are selected from the computing task queue as pre-computation tasks to be checked according to the processing priority.

[0148] The priority check flag is a flag used to mark a pre-computed task that failed to be executed under the current resource conditions, but should be re-evaluated and checked as the resource status improves. It can be implemented as a boolean field in the task object, a specific status code, or a separate list of priority check tasks. Its purpose is to distinguish those tasks that failed to be executed due to temporary resource shortages, so that they can be quickly identified and prioritized when resources become available.

[0149] After the real-time load status of the computing module changes, the system scheduling logic first checks whether there are tasks with priority check flags in the computing task queue. If so, it skips the regular priority sorting or polling process, directly selects the task with the flag, and matches its required resources with the available resources of the current computing module. Specifically, this can be achieved by maintaining a list of tasks with priority check flags and traversing the list for comparison when a load change event occurs, or by adding a pre-judgment step to the regular scheduling loop. The purpose is to ensure that tasks that were previously shelved due to insufficient resources can get a priority re-evaluation opportunity and increase their likelihood of being scheduled.

[0150] This application's solution schedules multiple pre-computation tasks in the computation task queue based on processing priority within the computation module. During the process of retrieving pre-computation tasks to be executed, if a comparison indicates that the real-time load status of the computation module does not meet the resource consumption attributes of the pre-computation task to be checked, the system does not simply postpone the task or wait at its original priority. Instead, it assigns a priority check flag to the task. This flag gives the task a special status in subsequent scheduling. Furthermore, after a change in the real-time load status of the computation module, the system proactively checks the computation task queue for pre-computation tasks with priority check flags. This proactive checking mechanism avoids indiscriminate scanning of the entire task queue, focusing instead on tasks previously blocked due to resource bottlenecks. Moreover, if a pre-computation task with a priority check flag exists, its resource consumption attributes are compared with the changed real-time load status of the computation module. This priority comparison strategy ensures that previously flagged tasks can be quickly re-evaluated when computational resources become available. When a new comparison result indicates that the real-time load status of the modified computing module meets its resource consumption attributes, the pre-computation task with the priority check flag is extracted as a pre-computation task to be executed, thus ensuring timely execution. If no pre-computation task with the priority check flag exists, or if the new comparison result indicates that the real-time load status of the modified computing module still does not meet its resource consumption attributes, the system will select other pre-computation tasks from the computing task queue as pre-computation tasks to be checked based on processing priority. This ensures that even when no task meets the priority execution conditions, the system can still schedule tasks according to the predetermined priority strategy, maintaining the overall task execution flow. Through this mechanism, the solution of this application can intelligently mark and prioritize the retry of blocked tasks when computing resources are temporarily insufficient, improving resource utilization and the response speed of high-priority tasks, thereby scheduling pre-computation tasks more efficiently and avoiding impact on logistics efficiency due to excessive waiting time.

[0151] In some preferred embodiments, for example, suppose there are multiple pre-computation tasks in the computation task queue, including a high-priority task A (requiring a large amount of CPU resources), a medium-priority task B (requiring medium memory resources), and a low-priority task C (requiring a small amount of network bandwidth). The current real-time load status of the computation module shows that CPU resources are highly strained, while memory and network resources are relatively abundant. Based on processing priority, the system first selects task A as the pre-computation task to be checked. The resource consumption attribute of task A (large amount of CPU resources) is compared with the current real-time load status of the computation module (highly strained CPU), and the comparison result shows that it does not meet the requirements. At this point, according to the scheme of this application, a priority check flag is set for task A. The system continues to check task B based on processing priority. The resource consumption attribute of task B (medium memory resources) is compared with the current real-time load status of the computation module (relatively abundant memory), and the comparison result shows that it meets the requirements. Therefore, task B is extracted as the pre-computation task to be executed and execution begins. After a period of time, task B is completed, and the CPU load of the computation module decreases due to the completion of other tasks, changing the real-time load status. The system checks the computation task queue and finds that task A has a priority check flag. It first compares the resource consumption attributes of task A with the real-time load status of the changed computation module. If the CPU load has decreased to a level that meets the requirements of task A, and the new comparison result shows that it does, then task A is extracted as a pre-computation task to be executed. If the changed CPU load still does not meet the requirements of task A, or if there are no other tasks with a priority check flag in the queue, the system will select task C or other unmarked tasks from the computation task queue as pre-computation tasks to be checked, based on processing priority.

[0152] Furthermore, when the comparison results indicate that the real-time load status of the computing module meets the resource consumption attributes, the step of extracting the pre-computation tasks to be checked from the computing task queue as pre-computation tasks to be executed includes:

[0153] Determine if there are multiple pre-computed tasks to be inspected that have the same highest business priority;

[0154] If it is determined that there are multiple pre-calculation tasks to be inspected with the same highest business priority, then these multiple pre-calculation tasks to be inspected with the same highest business priority are identified as a task group to be selected.

[0155] For each pre-computed task in the task group to be selected, obtain the current running status of the device instance associated with the pre-computed task, as well as the target running status required to execute the pre-computed task;

[0156] Based on the current running status and the target running status, determine the state switching cost corresponding to each pre-calculated task in the task group to be selected;

[0157] Based on the state switching cost, select a pre-computed task from the candidate task group as the pre-computed task to be executed;

[0158] Retrieve pre-computed tasks to be executed from the computation task queue;

[0159] If it is determined that there are no multiple pre-computed tasks to be inspected with the same highest business priority, then the pre-computed task to be inspected will be taken as the pre-computed task to be executed, and the pre-computed task to be executed will be extracted from the computation task queue.

[0160] When the real-time load status of the computing module meets the resource consumption attributes and there are multiple pre-computation tasks to be checked with the same highest business priority, instead of simply selecting randomly or sorting according to other secondary rules, the state switching cost of the device instance is introduced as a further screening criterion.

[0161] Specifically, the process begins by determining if multiple pre-computed tasks with the same highest business priority exist, a prerequisite for triggering subsequent optimization selection. If such tasks exist, they are identified as a group of tasks to be selected. For each pre-computed task in the group, the current running state of its associated device instance and the target running state required to execute the task are obtained; this provides the foundational data for calculating state switching costs. Based on the current and target running states, the state switching cost for each pre-computed task is determined, serving as the quantification selection criterion. According to the calculated state switching costs, the pre-computed task with the lowest state switching cost is selected from the group as the task to be executed, thereby reducing the state switching costs caused by task execution. If no multiple pre-computed tasks with the same highest business priority exist, the pre-computed task to be inspected is directly selected as the task to be executed. This refined selection mechanism based on state switching costs ensures that, in the event of priority conflicts, the task with the least impact on the system can be selected for execution, avoiding frequent state switching of device instances.

[0162] This approach combines the scheduling and filtering based on business priority, processing priority, and computing module load status from previous solutions, effectively solving the problem of frequent device state switching that may occur when multiple high-priority tasks compete, and improving system stability and resource utilization efficiency.

[0163] By employing the above technical solution, when there are multiple pre-calculation tasks to be inspected with the same highest business priority, the task with the lowest state switching cost is evaluated and selected for execution, thus avoiding frequent state switching of device instances, reducing unnecessary resource consumption, and improving the system's operational stability and efficiency.

[0164] This application further proposes a step for determining the state transition cost of each pre-calculated task in the task group to be selected, based on the current operating state and the target operating state, including:

[0165] Obtain data on the dynamic factors affecting the cost of this state transition;

[0166] By combining this dynamic factor data with the current operating state and the target operating state, a basis for determining the cost of switching states is obtained;

[0167] Based on the criteria used to determine the state transition cost, determine the state transition cost for each pre-calculated task in the task group to be selected.

[0168] Dynamic factor data refers to real-time changes in the external environment or system operation that affect the cost of equipment state switching. It can be obtained through sensor acquisition, system interface acquisition, or third-party data sources.

[0169] By determining the state switching cost for each pre-calculated task in the task selection group, this method no longer relies solely on the equipment's current and target operating states, but further acquires dynamic factors influencing the state switching cost. These dynamic factors, such as external environmental parameters or system load, more comprehensively reflect the actual difficulty and potential overhead of the equipment's state switching. Subsequently, this dynamic factor data is combined with the equipment's current operating state and the target operating state required to execute the task, forming a comprehensive basis. This basis considers both internal equipment state changes and external environmental influences. Finally, based on this comprehensive basis, the state switching cost for each pre-calculated task in the task selection group is accurately determined. In this way, the calculated state switching cost is closer to reality and can more accurately measure the actual cost required to execute different tasks. When multiple pre-calculated tasks with the same highest business priority exist, selection based on this more accurate state switching cost can more effectively identify the task with the lowest actual execution cost, thereby optimizing task scheduling decisions. This method overcomes the limitations of considering only the equipment's own state, making task selection more intelligent and refined, and helping to improve the overall operational efficiency and resource utilization of the logistics system.

[0170] The above technical solution considers dynamic factors influencing state switching costs when determining the state switching cost for each pre-calculated task in the task group to be selected. This dynamic factor data is combined with the current and target operating states to obtain the basis for determining the state switching cost. Based on this basis, the state switching cost for each pre-calculated task in the task group to be selected is determined. This results in a more accurate calculated state switching cost, more realistically reflecting the actual cost required to execute different tasks. When multiple pre-calculated tasks with the same highest business priority exist, selection based on this more accurate state switching cost can more effectively identify the task with the lowest actual execution cost, thereby optimizing task scheduling decisions and improving the overall operational efficiency and resource utilization of the logistics system.

[0171] On the other hand, such as Figure 2 As shown, an exemplary modular logistics system data analysis system is illustrated. This application further proposes a modular logistics system data analysis system 100, which includes:

[0172] The template creation module 10 is used to create a device function template. The device function template contains multiple component role slots, and each slot specifies the type of component to be received and key input and output parameters.

[0173] The script encapsulation module 20 encapsulates the logical relationship script in the device function template, wherein the logical relationship script defines the operation relationship of parameters between the role slots of each component;

[0174] The instance management module 30 is used to create a device instance based on the device function template and bind at least one component instance to the component role slot contained in the device function template associated with the device instance. The component instance is a functional constituent unit of the device instance, and the performance parameters of the component instance participate in the calculation of device performance indicators through the logical relationship script bound to the device instance.

[0175] The performance update module 40 is used to call the logical relationship script to recalculate the device performance index in response to the modification of the performance parameters of the first component instance, and update the calculation result to the performance index of the device instance, wherein the first component instance is one of the component instances in the device instance.

[0176] This application's solution defines equipment function templates through a template creation module, providing standardized structural descriptions and parameter interfaces for different types of logistics equipment. A script encapsulation module embeds logical relationship scripts into the templates, precisely defining the calculation rules between internal component parameters and overall performance indicators. An instance management module binds actual component instances to template-based equipment instances, establishing a connection between the physical world and the logical model. A performance update module responds to modifications in underlying component parameters and calls the logical relationship scripts bound to the equipment instances to accurately calculate and update equipment performance indicators. This modular, hierarchical system architecture allows for the flexible construction and management of equipment models of varying complexity. Furthermore, when underlying component parameters change, it accurately transmits the impact of these changes to upper-level equipment performance indicators through pre-defined logical scripts that reflect physical constraints, rather than relying on potentially distorted fixed aggregation algorithms. This provides a system foundation that effectively supports data analysis methods for hierarchical logistics systems, ensuring the accuracy and real-time nature of data analysis.

[0177] The above description is merely an embodiment of this application and is not intended to limit the scope of protection of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of protection of this application.

Claims

1. A data analysis method for a modular logistics system, characterized in that, include: Create a device function template, which contains multiple component role slots, each slot specifying the type of component to be received and key input / output parameters; The device function template encapsulates a logic relationship script, which defines the operational relationships between parameters of each component role slot. A device instance is created based on the device function template, and at least one component instance is bound to the component role slot contained in the device function template associated with the device instance. The component instance is a functional constituent unit of the device instance, and the performance parameters of the component instance participate in the calculation of device performance indicators through the logical relationship script bound to the device instance. In response to the modification of the performance parameters of the first component instance, the logical relationship script is invoked to recalculate the device performance metrics, and the calculation result is updated to the performance metrics of the device instance, wherein the first component instance is one of the component instances in the device instance.

2. The modular logistics system data analysis method according to claim 1, characterized in that, The step of calling the logical relationship script to recalculate the device performance metrics in response to a modification of the performance parameters of the first component instance, and updating the calculation result to the performance metrics of the device instance, includes: In response to a modification of the performance parameters of the first component instance, detect the first component role slot bound to the first component instance; The device performance metrics are recalculated by calling the corresponding logical relationship script based on the first component role slot, and the calculation result is updated as the performance metrics of the device instance.

3. The modular logistics system data analysis method according to claim 1, characterized in that, The step of calling the logical relationship script to recalculate the device performance metrics in response to a modification of the performance parameters of the first component instance, and updating the calculation result to the performance metrics of the device instance, includes: An early warning sensing area is set upstream of the device instance to obtain early warning information carrying the identity information of the logistics object before the logistics object arrives at the device instance; In response to the warning information, based on the modified performance parameters and the identity information of the logistics object, the logical relationship script is invoked to perform pre-calculation, and the first device performance index bound to the logistics object is obtained and cached. In response to a data query request issued for the logistics object, the first device performance index is extracted from the cache, and the performance index of the device instance is updated using the first device performance index.

4. The modular logistics system data analysis method according to claim 3, characterized in that, The step of responding to the warning information by calling the logical relationship script to perform pre-calculation based on the modified performance parameters and the identity information of the logistics object, and obtaining and caching the first equipment performance index bound to the logistics object, includes: In response to the warning information, a pre-calculated task associated with the identity information of the logistics object is generated; Based on the identity information of the logistics object, query the business priority associated with the logistics object; The pre-computation task is bound to the business priority and placed into a computation task queue; The computing module schedules multiple pre-computation tasks in the computing task queue according to the business priority, and extracts the pre-computation tasks to be executed from the computing task queue. For the pre-calculation task to be executed, the logical relationship script is invoked to perform pre-calculation based on the modified performance parameters and the identity information of the logistics object, so as to obtain and cache the first equipment performance index bound to the logistics object.

5. The modular logistics system data analysis method according to claim 4, characterized in that, The step of scheduling multiple pre-computation tasks in the computation task queue according to the business priority by the computation module, and extracting pre-computation tasks to be executed from the computation task queue includes: Monitor changes in the business attributes of logistics objects associated with pre-computation tasks already placed in the computation task queue to obtain business attribute change information containing the identity information of the logistics object and the new business priority. In response to the business attribute change information, the corresponding first pre-calculation task is retrieved from the calculation task queue based on the logistics object identity information; Update the processing priority bound to the first pre-calculation task according to the new business priority indicated by the business attribute change information; The computing module schedules multiple pre-computation tasks in the computing task queue according to the updated processing priority, and extracts pre-computation tasks to be executed from the computing task queue.

6. The modular logistics system data analysis method according to claim 5, characterized in that, The step of scheduling multiple pre-computation tasks in the computation task queue according to the updated processing priority by the computation module, and extracting pre-computation tasks to be executed from the computation task queue includes: Configure resource consumption attributes that characterize the computational load for each pre-computation task in the computation task queue; Obtain the real-time load status of the computing module; The computing module selects pre-computation tasks to be checked from the computing task queue according to the processing priority; The resource consumption attributes of the pre-computation task to be checked are compared with the real-time load status of the computing module to generate a comparison result. When the comparison result indicates that the real-time load status of the computing module meets the resource consumption attribute, the pre-computation task to be checked is extracted from the computing task queue as a pre-computation task to be executed.

7. The modular logistics system data analysis method according to claim 6, characterized in that, The step of scheduling multiple pre-computation tasks in the computation task queue according to the updated processing priority by the computation module, and extracting pre-computation tasks to be executed from the computation task queue includes: When the comparison result shows that the real-time load status of the computing module does not meet the resource consumption attributes of the pre-computation task to be checked, a priority check identifier is set for the pre-computation task to be checked. After the real-time load status of the computing module changes, check in the computing task queue whether there is a pre-computation task with the priority check flag set. If there is a pre-computation task with the priority check flag, the resource consumption attribute of the pre-computation task with the priority check flag is compared with the real-time load status of the changed computing module to generate a new comparison result; when the new comparison result shows that the real-time load status of the changed computing module meets its resource consumption attribute, the pre-computation task with the priority check flag is extracted as a pre-computation task to be executed. If there is no pre-computation task with the priority check flag set, or if the new comparison result shows that the real-time load status of the changed computing module still does not meet its resource consumption attributes, then other pre-computation tasks are selected from the computing task queue as pre-computation tasks to be checked according to the processing priority.

8. The modular logistics system data analysis method according to claim 7, characterized in that, When the comparison result indicates that the real-time load status of the computing module meets the resource consumption attribute, the step of extracting the pre-computation task to be checked from the computing task queue as the pre-computation task to be executed includes: Determine if there are multiple pre-computed tasks to be inspected that have the same highest business priority; If it is determined that there are multiple pre-calculation tasks to be inspected with the same highest business priority, then the multiple pre-calculation tasks to be inspected with the same highest business priority are determined as a task group to be selected. For each pre-computed task in the task group to be selected, obtain the current running state of the device instance associated with the pre-computed task, and the target running state required to execute the pre-computed task; Based on the current running state and the target running state, determine the state switching cost corresponding to each pre-calculated task in the task group to be selected; Based on the state switching cost, select a pre-computed task from the group of tasks to be selected as the pre-computed task to be executed; Extract the pre-computation task to be executed from the computation task queue; If it is determined that there are no multiple pre-computation tasks to be inspected with the same highest business priority, then the pre-computation task to be inspected is taken as a pre-computation task to be executed, and the pre-computation task to be executed is extracted from the computation task queue.

9. The modular logistics system data analysis method according to claim 8, characterized in that, The step of determining the state switching cost corresponding to each pre-calculated task in the task group to be selected based on the current running state and the target running state includes: Obtain dynamic factor data that affects the cost of the state transition; The dynamic factor data is combined with the current operating state and the target operating state to obtain the basis for determining the state switching cost; Based on the criteria used to determine the state switching cost, the state switching cost corresponding to each pre-calculated task in the task group to be selected is determined.

10. A modular logistics system data analysis system, characterized in that, The system includes: The template creation module is used to create device function templates. The device function template contains multiple component role slots, and each slot specifies the type of component to be received and the key input and output parameters. The script encapsulation module encapsulates the logical relationship script in the device function template, wherein the logical relationship script defines the operation relationship of parameters between the slots of each component role; The instance management module is used to create device instances based on the device function template and bind at least one component instance to the component role slots contained in the device function template associated with the device instance. The component instance is a functional constituent unit of the device instance, and the performance parameters of the component instance participate in the calculation of device performance indicators through the logical relationship script bound to the device instance. The performance update module is used to respond to the modification of the performance parameters of the first component instance by calling the logical relationship script to recalculate the device performance index and updating the calculation result to the performance index of the device instance, wherein the first component instance is one of the component instances in the device instance.

Images