An energy-saving-oriented edge service invocation sleep-wakeup control method and system

Abstract

The application discloses an energy-saving-oriented edge service calling dormancy wake-up control method and system, which comprises the following steps: collecting historical calling records of edge services and operation state data of associated construction equipment, and generating a business time sequence feature set; inputting the business time sequence feature set into a time sequence prediction model to generate a dormancy period table with a time boundary; triggering a hardware-level dormancy control during an idle period according to the dormancy period table, executing a dormancy control instruction, and recording the service operation state before dormancy and a dormancy state identifier into a non-volatile storage; in the dormancy state after executing the dormancy control instruction, when data packets meeting preset standards are identified, an interrupt signal is triggered to restore core power supply, the historical operation state and the dormancy state identifier are loaded from the non-volatile storage, and a service module wake-up response result is generated. By using the embodiment of the application, hardware-level energy-saving control and rapid state recovery can be realized, and the real-time response capability of business calling can be ensured.

Description

Technical Field

[0001] This invention belongs to the field of edge service technology, and in particular to a method and system for controlling the sleep and wake-up of edge service calls for energy saving. Background Technology

[0002] With the rapid development of the Industrial Internet of Things (IIoT) and edge computing, edge services play a crucial role in the intelligent management of construction equipment. However, edge devices typically operate under high loads for extended periods, leading to significant energy consumption, especially as they remain active even when not needed, resulting in resource waste. Traditional energy-saving methods primarily rely on dynamic frequency regulation or software hibernation, but these struggle to accurately match the complex business call patterns in construction scenarios and cannot simultaneously address the need for rapid wake-up. Furthermore, the operating status of construction equipment is highly dependent on work processes, and existing technologies do not adequately incorporate operational characteristics to predict service idle periods, resulting in insufficient timeliness and accuracy of hibernation strategies. While hardware-level hibernation can further reduce energy consumption, it lacks support for persistent service status and rapid recovery, potentially leading to business interruptions or response delays. Summary of the Invention

[0003] The purpose of this invention is to provide an energy-saving edge service call sleep / wake-up control method and system to overcome the shortcomings of the prior art, achieve hardware-level energy-saving control and rapid state recovery, and ensure the real-time response capability of service calls.

[0004] One embodiment of this application provides a method for controlling the sleep / wake-up of edge service calls in an energy-saving manner, the method comprising:

[0005] Collect historical call records of edge services and operation status data of associated construction equipment, extract periodic features and abnormal fluctuation features of call intervals through a sliding window, and generate a business time-series feature set with working condition tags;

[0006] The business time sequence feature set is input into the time sequence prediction model that integrates construction process dependencies to predict the business idle time period within a preset time period in the future. The optimal sleep window is calculated in reverse by combining the service start-up warm-up time, and a sleep cycle table with time boundaries is generated.

[0007] According to the aforementioned sleep cycle table, hardware-level sleep control is triggered during idle periods, sleep control instructions are executed, the core power supply circuit of the service module is cut off through the interrupt controller, the power supply to the wake-up detection circuit is retained, and the service running status and sleep status flag before sleep are recorded to non-volatile storage.

[0008] In the hibernation state after executing the hibernation control command, the data packets received by the edge are monitored in real time by a dedicated wake-up protocol detector. When a data packet that meets the preset standard is identified, an interrupt signal is triggered to restore the core power supply, and the historical running status and hibernation status identifier are loaded from non-volatile storage to generate the service module wake-up response result.

[0009] Optionally, the historical call records of the collected edge services and the operating status data of associated construction equipment are extracted using a sliding window to extract periodic and abnormal fluctuation features of the call intervals, generating a business time-series feature set with operating condition tags, including:

[0010] Collect historical call records of edge services within a preset number of days and operation logs of associated construction equipment, remove outliers through data cleaning, and generate a standardized raw dataset;

[0011] Based on the construction process, the working condition types are divided, and corresponding working condition labels are added to each record in the standardized original dataset. Typical working condition time periods are determined by clustering the working condition duration, and a time series dataset with working condition labels is generated.

[0012] Using dynamic sliding window technology, the window size is adaptively adjusted according to the working condition cycle. The time series dataset with working condition labels is segmented, and the mean, variance and peak frequency of the call interval within each window are calculated. Periodic features and abnormal fluctuation features are extracted to generate a feature vector set.

[0013] The feature vector set is associated with the corresponding working condition label, and dimensionality reduction is performed through principal component analysis to retain more than 95% of the feature contribution rate, thereby generating a business time series feature set with working condition labels.

[0014] Optionally, the step of inputting the business time-series feature set into a time-series prediction model that integrates construction procedure dependencies to predict business idle periods within a preset time frame, and then using the service startup warm-up time to back-calculate the optimal hibernation window to generate a hibernation periodic table with time boundaries includes:

[0015] The connection relationships between various construction processes are analyzed, a directed graph of process dependencies is constructed, the preparation time and connection interval of each process are marked, and a process sequence dependency model is generated.

[0016] The business time sequence feature set is aligned with the process time sequence dependency model. Through the dynamic time warping algorithm, the call interval in the business time sequence feature set is matched with the connection interval in the process dependency model to generate an aligned feature set with process weights.

[0017] The aligned feature set is input into a long short-term memory network model that integrates process-dependent weights to predict the business call blank periods within a preset hour in the future and generate an initial list of idle periods.

[0018] The historical service startup warm-up time is statistically analyzed, and the hibernation start time is calculated backwards from the start time of the initial idle time period list to determine the optimal hibernation window for each idle time period and generate a window candidate set.

[0019] Conflict detection is performed on the candidate window set, and a start time, end time, and corresponding operating condition label are added to each window to generate a sleep cycle table with time boundaries.

[0020] Optionally, according to the sleep cycle table, during idle periods, hardware-level sleep control is triggered, sleep control instructions are executed, the core power supply circuit of the service module is cut off through the interrupt controller, the power supply to the wake-up detection circuit is retained, and the service running state and sleep state identifier before sleep are recorded to non-volatile storage, including:

[0021] Parse the time boundaries in the hibernation cycle table. When the system time reaches the hibernation start time, trigger the hardware-level hibernation preparation process. Obtain the current running status of the service module, including process ID, memory usage, and data connection status, through the status detection interface, and generate a service status snapshot.

[0022] The service status snapshot is compressed and written to non-volatile storage. An incremental write method is used to save only the part that is different from the previous status, while recording the write time and check value to generate a status storage record.

[0023] The hibernation control instruction set is generated based on the state storage record. The instruction set includes the core power supply circuit cutoff timing, the power supply parameters maintained by the wake-up detection circuit and the state storage address, and is sent to the interrupt controller through the bus.

[0024] When the interrupt controller receives the hibernation control instruction set, it cuts off the power supply circuit of the core component of the service module in sequence, retains only the microampere power supply of the dedicated wake-up detection circuit, provides real-time feedback on the power supply switching result, and generates a power supply status switching log.

[0025] Write a hibernation state identifier containing the hibernation start time, corresponding window ID, and power supply switching result into non-volatile memory, and associate the state storage record with the power supply state switching log to complete hibernation triggering.

[0026] Optionally, in the hibernation state after executing the hibernation control command, a dedicated wake-up protocol detector monitors the data packets received at the edge in real time. When a data packet conforming to a preset standard is identified, an interrupt signal is triggered to restore core power supply. The historical operating state and hibernation state identifier are loaded from non-volatile memory, and a service module wake-up response result is generated, including:

[0027] In sleep mode, the dedicated wake-up protocol detector enters low-power monitoring mode, filters out irrelevant signals through preset hardware filtering circuits, retains only data packets of the engineering equipment communication frequency band, captures and temporarily stores received data packet fragments in real time, and generates a data packet queue to be parsed.

[0028] The fragments in the data packet queue to be parsed are reassembled, the device ID and instruction type fields in the packet header are extracted, and they are compared and verified with the preset standard containing the engineering equipment whitelist and wake-up instruction feature code. Data packets that pass the verification are marked as valid wake-up packets, and a verification result table is generated.

[0029] When a valid wake-up packet appears in the verification result table, the dedicated detector triggers an interrupt signal, which is sent to the power management unit through the wake-up pin. The power management unit restores the core power supply of the service module according to the preset timing sequence, and at the same time records the wake-up trigger time and packet characteristics, and generates a power restoration log.

[0030] Read state storage records and hibernation status identifiers from non-volatile storage, load service status snapshots, restore processes, memory data, and connections, compare the consistency between power restoration logs and hibernation status identifiers, and generate service module wake-up response results including wake-up time and service recovery status.

[0031] Another embodiment of this application provides an energy-saving edge service call sleep / wake-up control system, the system comprising:

[0032] The data acquisition module is used to collect historical call records of edge services and operating status data of associated construction equipment. It extracts periodic and abnormal fluctuation features of call intervals through a sliding window and generates a business time-series feature set with operating condition tags.

[0033] The input module is used to input the business time sequence feature set into the time sequence prediction model that integrates the construction process dependency relationship, predict the business idle time period within the future preset time, and back-calculate the optimal sleep window by combining the service start-up warm-up time to generate a sleep period table with time boundaries.

[0034] The control module is used to trigger hardware-level sleep control during idle periods according to the sleep cycle table, execute sleep control instructions, cut off the core power supply circuit of the service module through the interrupt controller, retain the power supply to the wake-up detection circuit, and record the service running status and sleep status identifier before sleep to non-volatile storage.

[0035] The monitoring module is used to monitor the data packets received by the edge in real time through a dedicated wake-up protocol detector in the sleep state after the execution of the sleep control command. When a data packet that meets the preset standard is identified, an interrupt signal is triggered to restore the core power supply, the historical running status and sleep status identifier are loaded from non-volatile storage, and the service module wake-up response result is generated.

[0036] Another embodiment of this application provides a storage medium storing a computer program, wherein the computer program is configured to execute the method described in any of the preceding claims when running.

[0037] Another embodiment of this application provides an electronic device including a memory and a processor, wherein the memory stores a computer program and the processor is configured to run the computer program to perform the method described in any of the preceding claims.

[0038] Compared with existing technologies, this invention provides an energy-saving edge service call hibernation and wake-up control method. It collects historical call records of edge services and associated construction equipment operation status data to generate a business time-series feature set. This feature set is then input into a time-series prediction model to generate a hibernation periodic table with time boundaries. Based on the periodic table, hardware-level hibernation control is triggered during idle periods, executing hibernation control commands and simultaneously recording the service operation status and hibernation status identifier before hibernation to non-volatile storage. In the hibernation state after executing the hibernation control commands, when a data packet conforming to a preset standard is detected, an interrupt signal is triggered to restore core power supply. The historical operation status and hibernation status identifier are loaded from non-volatile storage, generating a service module wake-up response result. This enables hardware-level energy-saving control and rapid status recovery, ensuring real-time response capabilities for business calls. Attached Figure Description

[0039] Figure 1 A hardware structure block diagram of a computer terminal for an energy-saving edge service call sleep / wake-up control method provided in an embodiment of the present invention;

[0040] Figure 2 A flowchart illustrating an energy-saving edge service call sleep / wake-up control method provided in an embodiment of the present invention;

[0041] Figure 3 This is a schematic diagram of a power-saving edge service call sleep / wake-up control system provided in an embodiment of the present invention. Detailed Implementation

[0042] The embodiments described below with reference to the accompanying drawings are exemplary and are only used to explain the present invention, and should not be construed as limiting the present invention.

[0043] This invention first provides an energy-saving edge service call sleep / wake control method, which can be applied to electronic devices, such as computer terminals, specifically ordinary computers.

[0044] The following detailed explanation uses a computer terminal as an example. Figure 1This is a hardware structure block diagram of a computer terminal for an energy-saving edge service call sleep / wake-up control method provided in an embodiment of the present invention. Figure 1 As shown, the computer device includes a processor, memory, and network interface connected via a system bus, wherein the memory may include non-volatile storage media and internal memory.

[0045] Non-volatile storage media can store operating systems and computer programs. These computer programs include program instructions that, when executed, cause the processor to perform any energy-efficient edge service call sleep / wake-up control method.

[0046] The processor provides computing and control capabilities, supporting the operation of the entire computer device.

[0047] Internal memory provides an environment for the execution of computer programs in non-volatile storage media. When the computer program is executed by the processor, it enables the processor to execute any energy-efficient edge service call sleep / wake control method.

[0048] This network interface is used for network communication, such as sending assigned tasks. Those skilled in the art will understand that... Figure 1 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0049] It should be understood that the processor can be a Central Processing Unit (CPU), but it can also be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. Among these, a general-purpose processor can be a microprocessor or any conventional processor.

[0050] See Figure 2 The present invention provides an energy-saving edge service call sleep / wake control method, which may include the following steps:

[0051] S201: Collect historical call records of edge services and operating status data of associated construction equipment, extract periodic features and abnormal fluctuation features of call intervals through a sliding window, and generate a business time-series feature set with working condition tags;

[0052] Specifically, it can collect historical call records of edge services within a preset number of days and operation logs of associated construction equipment, remove outliers through data cleaning, and generate a standardized raw dataset;

[0053] Data collection and preliminary processing:

[0054] The system first sets a preset number of days (e.g., 30 days) and synchronously extracts historical data from the service call log database of the edge computing nodes and the operational status monitoring systems of associated construction equipment (such as tower cranes, concrete pump trucks, and rebar processing machine tools). The call records include service request timestamps (accurate to milliseconds), call types (e.g., data query, equipment control command), and response times; equipment logs include equipment ID, operating mode (e.g., standby, low load, high load), and sensor readings (e.g., motor current, hydraulic pressure, temperature). The raw data is matched with the service call and equipment status with millisecond-level precision using a time alignment engine. For example, when a concrete pump truck issues an "aggregate ratio query" service request in "high-pressure pumping" mode, the system records the pump truck's oil pressure (unit: megapascals, MPa) and motor speed (unit: revolutions per minute, RPM) at that moment as associated data.

[0055] Outlier cleaning rules:

[0056] The cleaning process employs a multi-stage filtration mechanism:

[0057] Physical threshold filtering: Delete data that exceeds the physical limits of the equipment (such as records where the tower crane motor current is greater than 150% of the rated value).

[0058] Temporal continuity test: The sliding Z-score algorithm is used to detect abrupt changes (Z-score > 3.0 is considered abnormal), such as abnormally frequent requests where the service call interval suddenly drops to 0.1 seconds (the normal average is 5 seconds).

[0059] Association verification: If a device is in a "power off" state but has service call records, it is marked as conflicting data.

[0060] The cleaned dataset is standardized by converting timestamps to UNIX timestamps (in seconds) and normalizing numerical parameters (such as oil pressure values) to the [0,1] range (by subtracting the minimum value from the original value and then dividing by the data range).

[0061] Generate a standardized dataset:

[0062] The cleaned data is reassembled using a triplet structure of "timestamp-service call characteristic-device status characteristic". Each record contains:

[0063] Primary key: A globally unique serial number (e.g., UUID format).

[0064] Service characteristics: call type encoding (e.g., 101 represents a device control command), response time (unit: milliseconds).

[0065] Equipment characteristics: operating mode coding (e.g., 1-standby, 2-low load), sensor reading set (e.g., current value 12.3 amps A, oil pressure value 28.5 MPa).

[0066] The final result is a standardized raw dataset sorted in ascending order by timestamp, stored in a Parquet format file in a distributed file system (such as HDFS), with each file containing data for a single day and an MD5 checksum.

[0067] Based on the construction process, the working condition types are divided, and corresponding working condition labels are added to each record in the standardized original dataset. Typical working condition time periods are determined by clustering the working condition duration, and a time series dataset with working condition labels is generated.

[0068] Process-condition mapping modeling:

[0069] Based on the construction organization design document, core processes are divided (e.g., "foundation excavation", "reinforcement binding", "concrete pouring"). Each process is labeled with a work condition type (e.g., GX represents excavation, GJ represents reinforcement processing), and its equipment operating characteristics are clearly defined.

[0070] Foundation excavation: associated with high vibration frequency (>50 Hz) and short-term pauses (average interval <2 minutes) of the excavator.

[0071] Concrete pouring: Pump truck operates under continuous high pressure (>25MPa) and service calls are frequent (average interval <10 seconds).

[0072] Establish a process-equipment-service mapping table. For example, in the "rebar tying" process, the "stirrup angle calculation" service call of the CNC stirrup bending machine is marked as the working condition label GJ.

[0073] Dynamic operating condition labeling:

[0074] Add a work condition label to each record in the standardized original dataset:

[0075] Rule matching: If the equipment status meets the characteristics of a certain process (such as pump truck oil pressure > 25MPa for 5 minutes), it will be automatically marked as "HNT" (concrete pouring).

[0076] Manual verification: For data with ambiguous boundaries (such as oil pressure value of 15MPa), the labels are manually verified through the construction BIM model visualization interface.

[0077] After labeling, each record is expanded into a four-tuple: timestamp-service feature-equipment feature-operating condition label.

[0078] Clustering optimization for different working conditions and time periods:

[0079] Density-based clustering (DBSCAN) algorithm is used to aggregate consecutive time periods under the same operating conditions:

[0080] Input parameters: minimum duration of time period (MinDuration=10 minutes), maximum interval between adjacent time periods (MaxGap=5 minutes).

[0081] Clustering process: Consecutive records with the same label are merged into time periods. If the interval between two "HNT" labeled time periods is less than 5 minutes, they are merged into one working condition segment.

[0082] Output a typical working condition time period table, including: working condition label, time period start time, end time, and duration (unit: minutes). For example: the time period labeled HNT [2023-08-01 09:00:00, 2023-08-01 11:30:00], with a duration of 150 minutes.

[0083] Using dynamic sliding window technology, the window size is adaptively adjusted according to the working condition cycle. The time series dataset with working condition labels is segmented, and the mean, variance and peak frequency of the call interval within each window are calculated. Periodic features and abnormal fluctuation features are extracted to generate a feature vector set.

[0084] Dynamic window partitioning strategy:

[0085] The window size is dynamically adjusted according to the operating condition type:

[0086] Short-cycle operation (such as equipment commissioning, average duration 30 minutes): Window size = 5 minutes;

[0087] Long-cycle conditions (such as continuous pouring, with an average duration of 4 hours): Window size = 30 minutes.

[0088] The window sliding step is fixed at 1 minute to ensure that adjacent windows overlap. For example, in the "HNT" operating condition segment, the window slides forward by 1 minute every 30 minutes to generate a window sequence covering the entire time period.

[0089] Feature calculation within the window:

[0090] Calculate the service call records within each window:

[0091] Mean_Interval: The average time difference between adjacent calls within a window (in seconds);

[0092] Calling the interval variance (Var_Interval): reflects the degree of interval fluctuation (e.g., variance > 100 seconds). 2 (Indicates extreme instability).

[0093] Peak frequency (Peak_Freq): The percentage of times the call interval is less than 1 second (e.g., if there are 20 short intervals in 100 calls within a window, then Peak_Freq=0.2).

[0094] Simultaneously extract periodic features: detect the dominant frequency through Fast Fourier Transform (FFT) (e.g., a 0.1Hz peak indicates a periodic call every 10 seconds).

[0095] Abnormal fluctuation feature extraction:

[0096] The Local Outlier Factor (LOF) algorithm is used to identify outlier windows.

[0097] The input vector [Mean_Interval, Var_Interval, Peak_Freq] constitutes a three-dimensional feature.

[0098] Anomaly detection: Windows with an LOF value > 2.0 are marked as anomalies (e.g., a window with a mean of 5 seconds but a variance of 500 seconds). 2 ).

[0099] Finally, each window outputs a feature vector in the following format: [Working condition label, window start time, Mean_Interval, Var_Interval, Peak_Freq, Dominant frequency, LOF value].

[0100] The feature vector set is associated with the corresponding working condition label, and dimensionality reduction is performed through principal component analysis to retain more than 95% of the feature contribution rate, thereby generating a business time series feature set with working condition labels.

[0101] Feature-condition related storage:

[0102] Feature vectors are grouped and stored according to operating condition labels (e.g., vectors with all labels GJ are stored in the same partition). Each vector is associated with the start and end times of the original window and the device ID to which it belongs, forming an operating condition feature cube structure, which supports fast retrieval by operating condition type.

[0103] Principal component analysis dimensionality reduction:

[0104] Perform the following on the feature matrix of each working condition group (e.g., the GJ group contains 1000 7-dimensional vectors):

[0105] Covariance matrix calculation: Analyze the correlation between features (e.g., Mean_Interval and Peak_Freq are negatively correlated).

[0106] Eigenvalue decomposition: Principal components (PCs) with a cumulative contribution rate ≥ 95% are retained. For example, the original 7-dimensional features are reduced to 3-dimensional PCs.

[0107] PC1 = 0.6 × Mean_Interval + 0.3 × Var_Interval (contribution rate 70%)

[0108] PC2 = 0.5 × Peak_Freq - 0.4 × Dominant Frequency (Contribution Rate 20%)

[0109] PC3 = 0.7 × LOF value (contribution rate 5%).

[0110] A contribution rate of 95% means that the feature retains 95% of the information of the original data after dimensionality reduction, calculated by the proportion of feature values.

[0111] Generate the final feature set:

[0112] The dimensionality-reduced feature vectors are recombined in the following format: [Working Condition Label, Time Window ID, PC1 Value, PC2 Value, PC3 Value]. For example, a window vector for label GJ is: [GJ, W12345, 1.24, -0.57, 0.33].

[0113] The dataset is stored as a columnar database (such as Apache Parquet), with additional feature-interpreting metadata: PC1 represents "call stability", PC2 represents "peak periodicity", and PC3 represents "abnormal fluctuation intensity".

[0114] S202, input the business time sequence feature set into the time sequence prediction model that integrates construction procedure dependencies, predict the business idle time period within the future preset time, and combine the service start-up warm-up time to reverse calculate the optimal hibernation window and generate a hibernation period table with time boundaries.

[0115] Specifically, the connection between various construction processes can be sorted out, a directed graph of process dependencies can be constructed, the preparation time and connection interval of each process can be marked, and a process sequence dependency model can be generated.

[0116] The system first extracts a complete list of construction procedures from an engineering management platform (such as a BIM system or construction scheduling database). Taking concrete pouring as an example, typical procedures include: rebar tying, formwork installation, embedded part positioning, concrete pumping, vibration compaction, and curing. Logical dependencies between procedures are established by analyzing the start / end timestamps of procedures in historical construction logs. For example, formwork installation can only begin after more than 80% of the rebar tying is completed (strong dependency), while embedded part positioning can be performed concurrently with the last 20% of rebar tying (weak dependency). These dependencies are abstracted as Directed Graph Nodes (DGNs), each representing a procedure. Nodes are connected by arrowed edges, with the arrow direction indicating the execution order of the procedures. For example, "Rebar Tying → Formwork Installation" indicates that the former is a Predecessor Process (PP) for the latter. Each edge is labeled with two key parameters: Preparation Time (PT, e.g., 30 minutes after rebar tying is completed for formwork installation) and Transition Interval (TI, e.g., 10 minutes after acceptance for formwork relocation). This results in a Process Dependency Digraph (PDD) containing all process nodes, dependency edges, and time parameter annotations.

[0117] Precise labeling of time parameters relies on multi-source data fusion. Preparation time (PT) is obtained by statistically analyzing the average waiting time between adjacent processes in historical construction (e.g., extracting the interval data from the end of 100 rebar binding operations to the start of formwork installation, removing outliers, and taking the average). Connection interval (TI) is calculated in conjunction with equipment scheduling rules: for example, concrete pumping requires waiting for the mixer truck to arrive; its TI value is composed of the average transportation time estimated from vehicle GPS trajectory data (e.g., 25 minutes) plus the on-site connection time (e.g., 5 minutes). For processes with the possibility of parallel operation (e.g., embedded part positioning and rebar binding), they are represented by dashed edges in the diagram, and the minimum overlap time (MOT, e.g., both must operate in parallel for at least 15 minutes) is marked. Special constraints (e.g., concrete pouring must be carried out when the daily temperature is below 30℃) are transformed into environmental dependent nodes (EDNs), connected to relevant process nodes, and marked with effective time windows (e.g., 9:00-16:00). The final generated Process Temporal Dependency Model (PTDM) is a digital engineering flowchart that includes topology, time parameters, and constraints.

[0118] Model validation was performed using Discrete Event Simulation (DES). Inputting historical construction date (e.g., June 1, 2023) temperature data and equipment availability records, the PTDM simulation was run to simulate the daily work sequence. The simulation results were compared with actual construction logs (e.g., the predicted concrete pumping start time deviated from the actual record by less than 5 minutes). If the deviation exceeded a threshold (e.g., 10%), the PT or TI parameters in the directed graph were adjusted in reverse. After iterative optimization, PTDM accurately reflects the dynamic temporal relationships between work processes. For example, in the summer model, the concrete curing node is automatically associated with a Temperature Sensor Virtual Node (TSVN). When the simulated temperature exceeds 35°C, a curing extension mechanism is triggered (TI increases by 120 minutes). Thus, PTDM possesses the ability to predict dynamic temporal sequences adapting to different working conditions.

[0119] The business time sequence feature set is aligned with the process time sequence dependency model. Through the dynamic time warping algorithm, the call interval in the business time sequence feature set is matched with the connection interval in the process dependency model to generate an aligned feature set with process weights.

[0120] The Business Time-series Feature Set (BTFS) contains statistical values ​​of call intervals labeled with work conditions (e.g., the average service call interval is 120 seconds under the formwork installation work condition). The Process Time Dependency Model (PTDM) provides the theoretical process connection intervals (e.g., TI from formwork installation to concrete pumping = 40 minutes). Due to uncertainties in actual construction (e.g., equipment failure extending TI), the two need to be time-aligned. The alignment process is based on work condition time periods: all feature vectors of the "formwork installation" work condition in the BTFS are extracted (each vector corresponds to a 30-minute sliding window) and matched with the theoretical TI sequence corresponding to this work condition in the PTDM (a 40-minute standard interval generated by the process directed graph). The matching uses the Dynamic Time Warping (DTW) algorithm, which allows for flexible stretching / compression of the time axis to eliminate timing deviations.

[0121] DTW implementation consists of three steps: First, a distance matrix (DM) is constructed. The rows of the matrix correspond to the actual call interval sequence of BTFS (e.g., [115s, 125s, 118s...]), and the columns correspond to the theoretical TI sequence of PTDM ([40min, 40min...]). The Euclidean distance (ED) between the actual and theoretical values ​​is calculated for each matrix element. Second, the optimal warping path (OPP) is found: from the top left corner to the bottom right corner of the matrix, the path with the smallest cumulative distance is selected (e.g., allowing diagonal movement of the path indicates timing synchronization). Finally, the warping distance (WD) is calculated as a matching index (the smaller the WD, the better the matching). For example, when the actual template installation is delayed due to rainfall, causing the call interval to lengthen to 180 seconds, DTW will automatically match it to the TI=60-minute node in the "rainy day" mode of PTDM.

[0122] Process weights (PW) are generated based on the matching results: PW = 1 / (1+WD), with a value range of 0-1 (1 represents a perfect match). PW is added as a new feature to the original BTFS vector. For example, if the actual call interval sequence for a certain window has WD = 0.2 (high match), then PW = 0.83; for another window with WD = 1.2 (low match), PW = 0.45. This ultimately forms an Aligned Feature Set with Process Weights (AFS-PW). This process establishes a Scenario-Process Weight Mapping Table (SPWMT) in memory for subsequent prediction model calls.

[0123] The aligned feature set is input into a long short-term memory network model that integrates process-dependent weights to predict the business call blank periods within a preset hour in the future and generate an initial list of idle periods.

[0124] The Long Short-Term Memory Network (LSTM) model employs a three-layer structure: the input layer receives feature vectors (including PW values) from AFS-PW, the hidden layer has 128 neurons, and the output layer predicts the probability of service calls at future time points. The key innovation is the use of process weights (PW) as weighting coefficients in the attention mechanism. Specifically, in the hidden state calculation of LSTM, PW participates in the generation of the gating signal. Taking the forget gate as an example: the traditional input is the current feature x_t and the previous state h_{t-1}, while this model adds a PW factor, with the formula being forget gate strength ∝ PW × x_t (the higher the PW, the stronger the influence of historical process features). For example, when PW = 0.9 (indicating a high match between the current working condition and PTDM), the model will place more trust in the process interval patterns predicted by PTDM.

[0125] The model is trained using historical AFS-PW data and validated using a sliding prediction method: 24 consecutive hours of data are used, with the first 12 hours as input, predicting the service call status (0 / 1 binary labels) every 5 minutes for the next 12 hours. The loss function uses Focal Loss (FL), with increased weighting for difficult samples (such as calls due to sudden device failures). After training, the prediction process is deployed: Input is AFS-PW data from the previous 6 hours (including the latest PW), and output is the call probability value (CPV, a continuous 0-1 value) for each 5-minute window within a preset future duration (e.g., 8 hours). Periods with CPV < 0.05 (a configurable threshold) are marked as potential idle slots (PIS).

[0126] Idle Slot Merging Optimization: Multiple consecutive PISs are merged into a single idle slot (e.g., three adjacent 5-minute PISs are merged into a 15-minute slot). Invalid Slot Removal: Slots shorter than the minimum hibernation time (Minimum HibernationTime, MHT=3 minutes) are discarded. The final result is an Initial Idle Slot List (IISL), where each record includes a start time (ST), an end time (ET), and a confidence level (CL=1-CPV). For example, a predicted output of [ST=2023-07-20 14:00, ET=14:25, CL=0.97] indicates a 97% probability of no service calls during this slot.

[0127] Statistically calculate the warm-up time of the historical service, and inversely calculate the hibernation start time in combination with the start time of the initial idle period list to determine the optimal hibernation window corresponding to each idle period, and generate a window candidate set;

[0128] The service warm-up time (SWT) is statistically calculated through the monitoring system log: the time taken from receiving the wake-up instruction to the service being fully ready (such as loading the in-memory data and establishing a database connection). Extract the last 100 startup records, and calculate the dynamic warm-up time (DWT) = the 90th percentile time consumption (to ensure it is sufficient in 90% of scenarios) after removing outliers (such as more than 3 times the standard deviation of the mean). For example, it is statistically obtained that DWT = 45 seconds. The backward calculation mechanism (BCM) calculates the hibernation start time according to the formula: hibernation start time (HST) = idle period start time (ST) - DWT - safety margin (SM). Here, SM is used to cope with risks such as clock asynchronization, and the default value is 20% of DWT (such as 45s × 0.2 = 9 seconds). Continuing with the previous example: if ST = 14:00, then HST = 14:00 - 45s - 9s = 13:59:06.

[0129] The optimal hibernation window (OHW) needs to meet two constraints: 1) the window end time ≤ idle period end time (ET); 2) the window duration ≥ minimum effective hibernation time (MEHT). MEHT is determined by the energy consumption model: the energy consumption saved by hibernation needs to be greater than the energy consumption of wake-up, and the empirical value is 60 seconds. Calculate the window duration: window duration (WD) = ET - HST. If WD < MEHT (such as in the previous example WD = 25 minutes > 60 seconds), then retain the window; otherwise, discard it. Each OHW record contains: HST, hibernation end time (HET = ET), and the associated idle period ID.

[0130] Energy consumption optimization is performed when generating the Window Candidate Set (WCS): The estimated energy saving (ES) for each OHW is calculated as (WD - DWT) × dormant power. Windows with EES > 1000 joules are preferentially selected (configurable). For example, for an OHW with WD = 25 minutes and dormant power of 5 watts, the EES = (1500s - 45s) × 5J / s = 7275 joules. The final WCS is stored sorted by HST, and each entry contains: [Window ID, HST, HET, EES, associated operating condition label].

[0131] Conflict detection is performed on the candidate window set, and a start time, end time, and corresponding operating condition label are added to each window to generate a sleep cycle table with time boundaries.

[0132] Conflict detection (CD) includes three types of conflict handling:

[0133] 1) Time overlap conflict: Detect whether any two windows [HS T1, HE T1] and [HST2, HET2] in WCS overlap (HST1 < HET2 and HST2 < HET1). If they overlap, prioritize retaining the window with the larger EES.

[0134] 2) Scenario Transition Conflict: If the scenario labels of adjacent windows are different (e.g., window A is “rebar tying” and window B is “concrete curing”), and the interval is less than the scenario transition buffer time (STBT=5 minutes), then the windows are merged and marked as mixed scenario.

[0135] 3) Resource usage conflict: Query the device calendar (e.g., the vibrator charging period 14:00-14:30). If the OHW overlaps with the device's usage period, then remove that window.

[0136] After the conflict is resolved, add metadata to each window: Start Boundary Time (SBT) = HST (accurate to the second); End Boundary Time (EBT) = HET; Scenario Tag (ST) is taken from the scenario type associated with the idle period;

[0137] Additional execution strategy parameters: Wake-up Advance Time (WAT) = DWT + SM (e.g., 54 seconds in the previous example); Maximum Allowable Wake-up Delay (MWD) = 2 seconds (hardware guarantee indicator).

[0138] The generated Hibernation Schedule with Time Boundaries (HSTB) is stored in JSON format and includes:

[0139] {

[0140] "schedule_id": "SCH_20230720",

[0141] "windows": [

[0142] {

[0143] "window_id": "WIN_001",

[0144] "start_time": "2023-07-20 13:59:06",

[0145] "end_time": "2023-07-20 14:25:00",

[0146] "scenario_tag": "template_installation",

[0147] "wake_up_advance": 54,

[0148] "energy_saving": 7275

[0149] },

[0150] / / Other windows... ]

[0152] }

[0153] The table is pushed to the Hibernation Execution Engine (HEE) via a message queue and simultaneously written to non-volatile storage for backup. The periodic table is valid until the end of the last window and automatically expires after that timeout.

[0154] S203, according to the sleep cycle table, trigger hardware-level sleep control during idle periods, execute sleep control instructions, cut off the core power supply circuit of the service module through the interrupt controller, retain the power supply to the wake-up detection circuit, and record the service running status and sleep status identifier before sleep to non-volatile storage.

[0155] Specifically, the time boundaries in the hibernation cycle table can be parsed. When the system time reaches the hibernation start time, the hardware-level hibernation preparation process is triggered. The current running status of the service module, including process ID, memory usage, and data connection status, is obtained through the status detection interface, and a service status snapshot is generated.

[0156] The Sleep Cycle Table (SCT) is a structured data table that explicitly marks the start time (ST), end time (ET), and associated operating condition label for each sleep window (e.g., "concrete pouring interval" or "rebar binding preparation period"). The Central SleepScheduler (CSS) continuously monitors the System Clock (SC). When the difference between the current timestamp (CT) of the SC and the ST of a sleep window in the SCT is less than a preset threshold (e.g., 10 seconds), the CSS triggers a hardware-level sleep preparation process. This process first collects the real-time operating status of the service modules through the Status Detection Interface (SDI) provided by the operating system kernel. SDI polls the key metrics of the service modules at millisecond-level frequencies.

[0157] Process ID Set (PIDS): Lists the identifiers of all active service processes (e.g., PID 8080 for the Apache service, PID 3306 for the database service).

[0158] Memory Occupation Map (MOM): Records the real-time usage (in MB) of each process's heap memory (HM), stack memory (SM), and shared memory (SHM).

[0159] Data Connection State (DCS): This includes the number of TCP / UDP connections (e.g., the number of currently maintained database connections is 20), the list of socket descriptors (e.g., FD 1024-1040), and the network session key (SessionKey, SK).

[0160] CSS encapsulates the above data into a Service State Snapshot (SSS), storing it in a binary-text hybrid format and attaching a timestamp (Snapshot Timestamp, SST) and a Cyclic Redundancy Check Code (CRCC) to ensure integrity. For example, during a "nighttime equipment inspection downtime," CSS might capture an SSS containing: PID {1102, 1105}, memory usage {1102: 45MB, 1105: 32MB}, and database connection pool status "idle:15".

[0161] The service status snapshot is compressed and written to non-volatile storage. An incremental write method is used to save only the part that is different from the previous status, while recording the write time and check value to generate a status storage record.

[0162] After the Service State Snapshot (SSS) is generated, the storage optimization process begins. First, a lightweight compression engine (LCE) is invoked, employing the LZ4 algorithm to compress the SSS in real time, typically achieving a compression ratio of 60% of the original size. The compressed data (Compressed Snapshot, CS) is then stored in non-volatile storage (NVS, such as ferroelectric RAM or flash EEPROM) using a Delta Write Strategy (DWS). The core mechanism of DWS is:

[0163] On the first write, save the full SSS (e.g., 50KB in size);

[0164] Subsequent writes only record the differences from the previous snapshot (Delta, DL), such as updating only the changed process memory value (e.g., the memory of PID 1105 changes from 32MB to 33MB) or the newly added connection state;

[0165] Difference detection is achieved through a bitmap comparison algorithm (BCA), which only marks the changed data block address (DBA).

[0166] When writing to NVS, the system also records key metadata:

[0167] Write Time (WT): Greenwich Mean Time (GMT) accurate to milliseconds.

[0168] Checksum Value (CV): A unique 64-character identifier generated using the SHA-256 hash algorithm;

[0169] Storage Address Pointer (SAP): Points to the physical location of CS in NVS (e.g., 0xFE00-0xFF20).

[0170] The aforementioned metadata, together with the CS (Cybernetic Controller), constitutes a State Storage Record (SSR). For example, a write operation generates an SSR: WT=2025-04-11 02:00:00.123, CV="a1b2c3...", SAP=0xDEAD, DL_SIZE=2KB (containing only two memory block changes).

[0171] The hibernation control instruction set is generated based on the state storage record. The instruction set includes the core power supply circuit cutoff timing, the power supply parameters maintained by the wake-up detection circuit and the state storage address, and is sent to the interrupt controller through the bus.

[0172] After the State Storage Record (SSR) is generated, the Sleep Control Engine (SCE) converts it into an executable Sleep Control Instruction Set (SCIS). The SCIS contains three key types of instructions:

[0173] Core Power Cut Sequence (CPCS):

[0174] Step-by-step power-off strategy: Step 1 shuts down the main CPU (delay 100 milliseconds), Step 2 disconnects the memory power supply (delay 50 milliseconds), Step 3 disconnects the peripheral bus (such as PCIe) (delay 30 milliseconds).

[0175] Timing parameters include the delay value (DV) and voltage drop threshold (VDT, e.g., from 3.3V to 0.8V) for each step.

[0176] Wake-up Circuit Sustained Parameters (WCSP):

[0177] The circuitry that maintains power supply is limited to the Wake-up Protocol Detector (WPD) and its associated RF receiver module.

[0178] Supply voltage: 3.3V (nominal value ±5%); Maximum allowable current: 200 microamps (μA); State Storage Address (SSA): Directly references the SAP value in the SSR (e.g., 0xDEAD) for quick data location during wake-up.

[0179] SCIS uses a low-power serial bus (such as I) 2 The data is transmitted to the interrupt controller (IC) via C or SPI. The bus transmission uses Manchester encoding (ME) to ensure interference immunity, and the transmission rate is set to 100 kilobits per second (kbps). The SCIS instruction format is a TLV (Type-Length-Value) structure. For example, the type field "0x01" represents a CPCS instruction, and the length field "0x0C" indicates that the following 12 bytes contain three sets of delay parameters (4 bytes each).

[0180] When the interrupt controller receives the hibernation control instruction set, it cuts off the power supply circuit of the core component of the service module in sequence, retains only the microampere power supply of the dedicated wake-up detection circuit, provides real-time feedback on the power supply switching result, and generates a power supply status switching log.

[0181] Upon receiving the SCIS, the interrupt controller (IC) initiates a hardware-level power-down execution process. The IC's built-in instruction parser (IP) decodes the CPCS timing and drives the multiple power control relays (PCRs) to perform a step-by-step power-down:

[0182] When the main CPU is powered off: the IC sends a "PWRDOWN" signal to the CPU power management chip (such as TI TPS65261) to trigger the undervoltage lockout (UVLO) mechanism, which reduces the core voltage (V_CORE) from 1.2V to 0V within 100 milliseconds;

[0183] Memory power failure: via I 2 Configure the DDR power controller (such as ISL95812) on the C bus to shut down the memory power rail (V_DDR) and delay for 50 milliseconds to ensure data silence;

[0184] Peripheral bus power failure: Control MOSFET switch (such as AO3400) to disconnect the 12V power supply (V_PCIE) of PCIe slot after a delay of 30 milliseconds.

[0185] During power outages, the IC strictly maintains power supply to the Wake-up Detection Circuit (WDC):

[0186] Power source: Independent low dropout linear regulator (LDO, such as MCP1700);

[0187] Power supply specifications: 3.3V±0.1V, current limited to 200 microamps (actual measured value is usually 150 microamps).

[0188] The IC monitors the voltage / current values ​​of each power supply circuit in real time and generates a Power State Switch Log (PSSL) to record:

[0189] Actual delay of each step (e.g., CPU power failure time is 102 milliseconds).

[0190] Voltage drop curve sampling points (e.g., recording the V_CORE value every 5 milliseconds);

[0191] Abnormal event flags (such as "0.5V ​​residual memory power supply").

[0192] PSSL is temporarily stored in the IC's buffer (Buffer Size: 512 bytes) in binary format and is eventually uploaded to the central log system via the UART interface.

[0193] Write a hibernation state identifier containing the hibernation start time, corresponding window ID, and power supply switching result into non-volatile memory, and associate the state storage record with the power supply state switching log to complete hibernation triggering.

[0194] After power is cut off, the IC triggers the sleep state identifier writing process. The Sleep Management Agent (SMA) writes the sleep state identifier (SSID) to a dedicated area (addresses 0xF000-0xF0FF) in the non-volatile memory (NVS). Its data structure includes:

[0195] Sleep Start Time (SST): A precise timestamp taken from the system clock (format: YYYYMMDDHHMMSSmmm).

[0196] Sleep Window ID (SWID): A unique identifier that references the Sleep Cycle Table (SCT) (e.g., "SW_20250411_0200").

[0197] Power Switch Result (PSR): A simplified summary of key PSSL information, including: a list of components that were successfully powered down (e.g., "CPU: OK, DDR: OK"); measured power supply values ​​for the wake-up circuit (e.g., "WDC_VOLTAGE: 3.28V"); and exception codes (if any, e.g., "ERR_DDR_RESIDUAL: 0.2V").

[0198] SSID is bound to previously stored data through the Association Engine (AE): Status Storage Record (SSR) association: Matching the "SST" field in SSID with the "WT" field in SSR to establish a bidirectional pointer (e.g., SSID→SSR: 0xDEAD, SSR→SSID: 0xF000); Power State Switching Log (PSSL) association: Mapping the "PSR" field in SSID to the storage address of PSSL (e.g., NVS address 0xE000).

[0199] After the association is complete, the SMA broadcasts a "sleep complete" event (Event Code: 0x8F) to the system. The event payload includes the SSID address and checksum. At this point, the service module officially enters sleep mode (power consumption < 1 milliwatt), with only the wake-up detection circuit remaining active.

[0200] S204, in the hibernation state after executing the hibernation control command, the data packets received by the edge are monitored in real time by a dedicated wake-up protocol detector. When a data packet that meets the preset standard is identified, an interrupt signal is triggered to restore the core power supply, the historical running state and hibernation state identifier are loaded from non-volatile storage, and the service module wake-up response result is generated.

[0201] Specifically, in sleep mode, the dedicated wake-up protocol detector can enter a low-power monitoring mode, filter out irrelevant signals through a preset hardware filtering circuit, retain only data packets in the communication frequency band of the engineering equipment, capture and temporarily store received data packet fragments in real time, and generate a queue of data packets to be parsed.

[0202] Low power monitoring mode activated:

[0203] When the core power supply to the service module is cut off, the Dedicated Wake-up Protocol Detector (DWPD) automatically switches to Low-Power Monitoring Mode (LPMM). This mode disables unnecessary internal functions (such as the high-speed clock tree and multi-channel ADC converter), retaining only the basic RF receiver link and signal preprocessing circuitry. The detector's operating voltage drops from the standard 3.3 volts (V) to 1.2 volts (V), and current consumption decreases from the milliampere (mA) level to the microampere (μA) level, typically 15 microamperes (μA). At this time, the DWPD's RF front-end (RFFE) continuously scans preset engineering equipment communication frequency bands (such as the 400-450 MHz industrial wireless band or the 2.4 GHz Zigbee band), but the receiver sensitivity is adjusted to -85 dBm, lower than the -110 dBm of the operating mode, to further reduce power consumption.

[0204] Hardware filtering circuit signal filtering:

[0205] All raw signals entering the RF front end first pass through a pre-set hardware filter circuit (HFC). This circuit consists of two stages:

[0206] The first-stage bandpass filter (BPF) employs a surface acoustic wave filter (SAWF) with a center frequency set to the target frequency band (e.g., 433MHz), a bandwidth of 2 MHz, and attenuation of out-of-band signals by at least 40 dB. For example, it can completely block common mobile phone 4G signals (1.8 GHz) or Wi-Fi signals (5 GHz).

[0207] The second-stage digitally tunable filter (DTF) implements a finite impulse response (FIR) filtering algorithm based on a field-programmable gate array (FPGA), dynamically adjusting the passband range according to the current operating condition label. For example, under the "concrete pouring" condition, only the characteristic frequency of data packets with the device ID "CEM-MIXER-XX" is allowed. After two stages of filtering, only signals within the valid frequency band are retained and sent to the packet detection module.

[0208] Packet capture and queue generation:

[0209] The packet detection module uses a sliding window capture mechanism (SWCM):

[0210] When a signal strength exceeding -80 dBm is detected and lasts for 0.5 ms, it is determined to be the start of a valid data packet.

[0211] The signal is sampled at a rate of 1 megabit per second (Mbps), and each data packet is divided into a fixed 128-byte fragment, with a timestamp (TS) and a signal strength tag (RSSI tag, RT) added.

[0212] Fragments are temporarily stored in a circular buffer (CB) of depth 8. When the buffer is full or remains silent for more than 5 milliseconds, the buffer contents are packaged into packet units (PUs), a header check sequence (HCS) is added, and the packet is pushed to the pending parsing packet queue (PPPQ). This queue uses a first-in, first-out (FIFO) management strategy, with a maximum capacity of 16 packet units. When overflowing, the oldest unit is discarded.

[0213] The fragments in the data packet queue to be parsed are reassembled, the device ID and instruction type fields in the packet header are extracted, and they are compared and verified with the preset standard containing the engineering equipment whitelist and wake-up instruction feature code. Data packets that pass the verification are marked as valid wake-up packets, and a verification result table is generated.

[0214] Data packet reassembly and field extraction:

[0215] The Verification Engine (VE) retrieves a Unit of Packet (PU) from the header of the Packet Parsing Queue (PPPPQ) and performs reassembly.

[0216] Fragment sorting: Concatenate 128-byte fragments in sequence based on timestamp (TS) and internal sequence number (SN);

[0217] Packet header parsing: Locate the packet header start flag (fixed to 0xAA55), and extract key fields according to the protocol format:

[0218] Device ID Field (DIDF): occupies 6 bytes, such as the ASCII encoding of "CEM-MIXER-01"; Command Type Field (CTF): occupies 1 byte, such as 0x01 representing "device startup command";

[0219] Integrity verification: Calculate the cyclic redundancy check code (CRC-16) in the packet header and compare it with the value stored in the packet. Discard packets that fail the verification.

[0220] Preset standard dynamic loading:

[0221] The preset criteria (PC) are stored in the detector's read-only memory (ROM) and contain two types of key data:

[0222] Engineering Device Whitelist (EDWL): Stores authorized device IDs and their hash values ​​(such as SHA-256 digests) in the form of a hash table. For example, a key-value pair: Key="CEM-MIXER" → Value=0x9f86d081...;

[0223] Wake-up Command Feature Code (WCFC): Defines the bit pattern of a valid wake-up command. For example, when the command type is 0x01 (start command), the data packet length must be 64 bytes and bytes 32-33 must be 0x10FF.

[0224] The whitelist and signature can be updated via non-volatile storage, and digital signature verification is required during the update.

[0225] Comparison and verification and result labeling:

[0226] The verification process is executed in two stages:

[0227] Whitelist verification: Calculate the hash value of the extracted Device ID field (DIDF) and query the Engineering Device Whitelist (EDWL). If a match is found, proceed to the next level; otherwise, discard.

[0228] Signature verification: The instruction type field (CTF) and the packet payload content are compared bit by bit with the wake-up command signature (WCFC). For example, when detecting CTF=0x01, it verifies whether the 2 bytes at payload offset 32 ​​are 0x10FF.

[0229] Data packets that pass the two-level verification are marked as valid wake-up packets (VWP), and their device ID, command type, and reception time (accurate to 0.1 milliseconds) are recorded in the Verification Result Table (VRT). This table is a fixed 8-row memory structure, with each row containing the verification status (1 byte), timestamp (4 bytes), and device ID (6 bytes). When overflow occurs, the oldest record is overwritten.

[0230] When a valid wake-up packet appears in the verification result table, the dedicated detector triggers an interrupt signal, which is sent to the power management unit through the wake-up pin. The power management unit restores the core power supply of the service module according to the preset timing sequence, and at the same time records the wake-up trigger time and packet characteristics, and generates a power restoration log.

[0231] Interrupt signal triggering mechanism:

[0232] The Dedicated Wake-up Protocol Detector (DWPD) scans the Verification Result Table (VRT) in real time. When any row is detected to have a verification status of "valid" (status value = 0x01):

[0233] Immediately freeze the current packet processing pipeline and save the current state to the register file;

[0234] Read the device ID (DID) and instruction type (CT) of the valid wake-up packet (VWP) from the VRT, and generate an interrupt feature code (IFC) in the format: DID (6 bytes) + CT (1 byte) + timestamp (4 bytes);

[0235] A high-level interrupt signal is sent to the Power Management Unit (PMU) via the wake-up pin (WP, defined in hardware as GPIO12), with a fixed pulse width of 50 microseconds (μs). At the same time, the interrupt signature (IFC) is written in parallel to the 16-bit data bus (DB).

[0236] Power restoration preset timing:

[0237] Upon receiving an interrupt signal, the Power Management Unit (PMU) executes a four-level Power Restoration Sequence (PRS):

[0238] T0 phase (0-5 ms): Activates the enable pin of the Core Voltage Regulator (CVR), but the output remains off;

[0239] T1 phase (5-10 ms): The core voltage is gradually increased to 1.0 volt (V) at a slope of 0.1 volt (V) / millisecond (ms) to prevent inrush current;

[0240] T2 phase (10-15 ms): Releases the clock generator (CG) reset and outputs an initial low-frequency clock (e.g., 1 MHz).

[0241] T3 phase (15-20 ms): The core voltage rises to the nominal 3.3 volts (V), the clock switches to full speed (e.g., 100 MHz), and a "Power Ready Signal" (PRS) is sent to the detector.

[0242] The entire process is controlled by the Timing State Machine (TSM) inside the PMU, and the timeout threshold for each stage is set to 120% of the nominal value.

[0243] Power restoration log generation:

[0244] During startup in phase T0, the PMU begins recording key parameters:

[0245] Wake-up Trigger Time (WTT): Derived from the real-time clock (RTC), with an accuracy of ±1 millisecond (ms);

[0246] Packet Features (PF): Directly stores the received interrupt signature (IFC);

[0247] Power Parameters (PP): including actual voltage values ​​(sampling rate 1 kHz), peak current (PC), and timing deviation (TD) at each stage.

[0248] The above data is packaged in binary format as a Power Restoration Log (PRL) and written to the PMU's built-in 512-byte non-volatile cache (NVC). After the log is generated, DMA transfer to the main non-volatile storage is triggered.

[0249] Read state storage records and hibernation status identifiers from non-volatile storage, load service status snapshots, restore processes, memory data, and connections, compare the consistency between power restoration logs and hibernation status identifiers, and generate service module wake-up response results including wake-up time and service recovery status.

[0250] Hibernation data loading and verification:

[0251] After the core power supply of the service module is stable, the bootloader executes:

[0252] Locate the storage record: Based on the pointer (PT) in the hibernation state identifier (HSI), locate the state storage record (SSR) and hibernation state identifier (HSI body) in the non-volatile storage (NVS);

[0253] Data integrity verification: Calculate the CRC-32 check value of the SSR and compare it with the reference value stored in the HSI; verify the digital signature of the HSI (ECDSA-256 algorithm) to ensure that it has not been tampered with.

[0254] Incremental data reconstruction: If the SSR is an incremental storage (recording the differences from the previous state), the base image (BI) needs to be loaded and the difference patch (DP) applied to reconstruct the complete service state snapshot (SSS).

[0255] State recovery and system rebuild:

[0256] After the operating system kernel takes over, restore the system based on the snapshot content:

[0257] Process recovery: Reconstruct the process tree from the snapshot's Process Control Block (PCB) table. For example, recover the "data_processor" process with process ID=1024 and reset the program counter (PC) to the sleep point address;

[0258] Memory restore: Write the memory page data (MPD) from the snapshot back to physical memory according to the Virtual Address Mapping Table (VAMT), and mark dirty pages as needing to be written back.

[0259] Connection Reconstruction:

[0260] Network connection: Based on the TCP quadruple (source IP, source port, destination IP, destination port) and sequence number (SN) in the snapshot, send TCP Keep-Alive packets to maintain the session;

[0261] Device connection: Send a "Status Sync Request" (SSR) to the associated construction equipment. If an acknowledgment is received, restore the I / O channel.

[0262] Wake-up response result generation:

[0263] After the service module has fully recovered, the Diagnostic Module (DM) executes:

[0264] Consistency comparison: Extract the Wake-up Trigger Time (WTT) from the Power Recovery Log (PRL) and the Hibernation Start Time (HST) from the Hibernation Status Identifier (HSI), and calculate the Actual Hibernation Duration (AHD). Compare the AHD with the Planned Duration (PD) in the hibernation cycle table; if the deviation exceeds 10%, it is marked as an anomaly.

[0265] Service status check:

[0266] Process survival rate: Statistical analysis of the number of recovered processes / the number of original processes, with a threshold of ≥95%; Memory consistency: Verify the hash values ​​of key data structures (such as the hash of the memory pool allocation table); Connection availability: Test the response latency of construction equipment commands (e.g., a response within 200 milliseconds is considered normal).

[0267] Generate response results: The summarized data is the Service Module Wake-up Response Result (SWMRR), which includes: wake-up time (system clock time); Service Recovery Status (SRS): bitmap encoding (Bit 0 = process status, Bit 1 = memory status, Bit 2 = connection status); Consistency Report (CR): includes AHD deviation value and detailed results of each check item.

[0268] The result is uploaded to the central control system via the edge service interface and written to the local log.

[0269] As can be seen, by collecting historical call records of edge services and associated construction equipment operation status data, a business time-series feature set is generated. This feature set is then input into a time-series prediction model to generate a sleep cycle table with time boundaries. Based on the sleep cycle table, hardware-level sleep control is triggered during idle periods, executing sleep control commands and simultaneously recording the service operation status and sleep status identifier before sleep to non-volatile storage. In the sleep state after executing the sleep control command, when a data packet conforming to preset standards is detected, an interrupt signal is triggered to restore core power supply. The historical operation status and sleep status identifier are loaded from non-volatile storage, and a service module wake-up response result is generated. This enables hardware-level energy-saving control and rapid state recovery, ensuring real-time response capability for business calls.

[0270] Another embodiment of the present invention provides an energy-saving edge service call sleep / wake-up control system, see [link to relevant documentation]. Figure 3 The system may include:

[0271] The acquisition module 301 is used to collect historical call records of edge services and operating status data of associated construction equipment. It extracts periodic features and abnormal fluctuation features of call intervals through a sliding window and generates a business time-series feature set with working condition tags.

[0272] Input module 302 is used to input the business time sequence feature set into the time sequence prediction model that integrates construction procedure dependency relationship, predict the business idle time period within the future preset time period, and back-calculate the optimal sleep window in combination with the service start-up warm-up time to generate a sleep period table with time boundary.

[0273] Control module 303 is used to trigger hardware-level sleep control during idle periods according to the sleep cycle table, execute sleep control instructions, cut off the core power supply circuit of the service module through the interrupt controller, retain the power supply to the wake-up detection circuit, and record the service running status and sleep status identifier before sleep to non-volatile storage.

[0274] The monitoring module 304 is used to monitor the data packets received by the edge in real time through a dedicated wake-up protocol detector in the sleep state after executing the sleep control command. When a data packet that meets the preset standard is identified, an interrupt signal is triggered to restore the core power supply, the historical running status and sleep status identifier are loaded from non-volatile storage, and a service module wake-up response result is generated.

[0275] This invention also provides a storage medium storing a computer program, wherein the computer program is configured to execute the steps in any of the above method embodiments when running.

[0276] This invention also provides an electronic device, including a memory and a processor, wherein the memory stores a computer program, and the processor is configured to run the computer program to perform the steps in any of the above method embodiments.

[0277] Specifically, the aforementioned electronic device may further include a transmission device and an input / output device, wherein the transmission device is connected to the aforementioned processor, and the input / output device is connected to the aforementioned processor.

[0278] The above description, based on the embodiments shown in the figures, details the structure, features, and effects of the present invention. The above description is only a preferred embodiment of the present invention, but the present invention is not limited to the scope of implementation shown in the figures. Any changes made in accordance with the concept of the present invention, or equivalent embodiments modified to have equivalent changes, that do not exceed the spirit covered by the specification and figures, should be within the protection scope of the present invention.

Claims

1. A method for controlling sleep / wake-up calls of edge services for energy saving, characterized in that, The method includes: Collect historical call records of edge services and operation status data of associated construction equipment, extract periodic features and abnormal fluctuation features of call intervals through a sliding window, and generate a business time-series feature set with working condition tags; The business time sequence feature set is input into the time sequence prediction model that integrates construction process dependencies to predict the business idle time period within a preset time period in the future. The optimal sleep window is calculated in reverse by combining the service start-up warm-up time, and a sleep cycle table with time boundaries is generated. According to the aforementioned sleep cycle table, hardware-level sleep control is triggered during idle periods, sleep control instructions are executed, the core power supply circuit of the service module is cut off through the interrupt controller, the power supply to the wake-up detection circuit is retained, and the service running status and sleep status flag before sleep are recorded to non-volatile storage. In the hibernation state after executing the hibernation control command, the data packets received by the edge are monitored in real time by a dedicated wake-up protocol detector. When a data packet that meets the preset standard is identified, an interrupt signal is triggered to restore the core power supply, and the historical running status and hibernation status identifier are loaded from non-volatile storage to generate the service module wake-up response result.

2. The method according to claim 1, characterized in that, The historical call records of the collected edge services and the operating status data of associated construction equipment are extracted using a sliding window to extract periodic and abnormal fluctuation features of the call intervals, generating a business time-series feature set with operating condition tags, including: Collect historical call records of edge services within a preset number of days and operation logs of associated construction equipment, remove outliers through data cleaning, and generate a standardized raw dataset; Based on the construction process, the working condition types are divided, and corresponding working condition labels are added to each record in the standardized original dataset. Typical working condition time periods are determined by clustering the working condition duration, and a time series dataset with working condition labels is generated. Using dynamic sliding window technology, the window size is adaptively adjusted according to the working condition cycle. The time series dataset with working condition labels is segmented, and the mean, variance and peak frequency of the call interval within each window are calculated. Periodic features and abnormal fluctuation features are extracted to generate a feature vector set. The feature vector set is associated with the corresponding working condition label, and dimensionality reduction is performed through principal component analysis to retain more than 95% of the feature contribution rate, thereby generating a business time series feature set with working condition labels.

3. The method according to claim 2, characterized in that, The step involves inputting the business time-series feature set into a time-series prediction model that integrates construction process dependencies to predict business idle periods within a preset timeframe. This is combined with the service startup warm-up time to reverse-calculate the optimal hibernation window, generating a hibernation periodicity table with time boundaries. The connection relationships between various construction processes are analyzed, a directed graph of process dependencies is constructed, the preparation time and connection interval of each process are marked, and a process sequence dependency model is generated. The business time sequence feature set is aligned with the process time sequence dependency model. Through the dynamic time warping algorithm, the call interval in the business time sequence feature set is matched with the connection interval in the process dependency model to generate an aligned feature set with process weights. The aligned feature set is input into a long short-term memory network model that integrates process-dependent weights to predict the business call blank periods within a preset hour in the future and generate an initial list of idle periods. The historical service startup warm-up time is statistically analyzed, and the hibernation start time is calculated backwards from the start time of the initial idle time period list to determine the optimal hibernation window for each idle time period and generate a window candidate set. Conflict detection is performed on the candidate window set, and a start time, end time, and corresponding operating condition label are added to each window to generate a sleep cycle table with time boundaries.

4. The method according to claim 3, characterized in that, According to the sleep cycle table, during idle periods, hardware-level sleep control is triggered, sleep control instructions are executed, the core power supply circuit of the service module is cut off through the interrupt controller, the power supply to the wake-up detection circuit is retained, and the service running state and sleep state flag before sleep are recorded to non-volatile memory, including: Parse the time boundaries in the hibernation cycle table. When the system time reaches the hibernation start time, trigger the hardware-level hibernation preparation process. Obtain the current running status of the service module, including process ID, memory usage, and data connection status, through the status detection interface, and generate a service status snapshot. The service status snapshot is compressed and written to non-volatile storage. An incremental write method is used to save only the part that is different from the previous status, while recording the write time and check value to generate a status storage record. The hibernation control instruction set is generated based on the state storage record. The instruction set includes the core power supply circuit cutoff timing, the power supply parameters maintained by the wake-up detection circuit and the state storage address, and is sent to the interrupt controller through the bus. When the interrupt controller receives the hibernation control instruction set, it cuts off the power supply circuit of the core component of the service module in sequence, retains only the microampere power supply of the dedicated wake-up detection circuit, provides real-time feedback on the power supply switching result, and generates a power supply status switching log. Write a hibernation state identifier containing the hibernation start time, corresponding window ID, and power supply switching result into non-volatile memory, and associate the state storage record with the power supply state switching log to complete hibernation triggering.

5. The method according to claim 4, characterized in that, In the sleep state following the execution of the sleep control command, a dedicated wake-up protocol detector monitors the data packets received at the edge in real time. When a data packet conforming to a preset standard is detected, an interrupt signal is triggered to restore core power supply. The historical operating state and sleep state identifier are loaded from non-volatile memory, and a service module wake-up response result is generated, including: In sleep mode, the dedicated wake-up protocol detector enters low-power monitoring mode, filters out irrelevant signals through preset hardware filtering circuits, retains only data packets of the engineering equipment communication frequency band, captures and temporarily stores received data packet fragments in real time, and generates a data packet queue to be parsed. The fragments in the data packet queue to be parsed are reassembled, the device ID and instruction type fields in the packet header are extracted, and they are compared and verified with the preset standard containing the engineering equipment whitelist and wake-up instruction feature code. Data packets that pass the verification are marked as valid wake-up packets, and a verification result table is generated. When a valid wake-up packet appears in the verification result table, the dedicated detector triggers an interrupt signal, which is sent to the power management unit through the wake-up pin. The power management unit restores the core power supply of the service module according to the preset timing sequence, and at the same time records the wake-up trigger time and packet characteristics, and generates a power restoration log. Read state storage records and hibernation status identifiers from non-volatile storage, load service status snapshots, restore processes, memory data, and connections, compare the consistency between power restoration logs and hibernation status identifiers, and generate service module wake-up response results including wake-up time and service recovery status.

6. A power-saving edge service call sleep / wake-up control system, characterized in that, The system includes: The data acquisition module is used to collect historical call records of edge services and operating status data of associated construction equipment. It extracts periodic and abnormal fluctuation features of call intervals through a sliding window and generates a business time-series feature set with operating condition tags. The input module is used to input the business time sequence feature set into the time sequence prediction model that integrates the construction process dependency relationship, predict the business idle time period within the future preset time, and back-calculate the optimal sleep window by combining the service start-up warm-up time to generate a sleep period table with time boundaries. The control module is used to trigger hardware-level sleep control during idle periods according to the sleep cycle table, execute sleep control instructions, cut off the core power supply circuit of the service module through the interrupt controller, retain the power supply to the wake-up detection circuit, and record the service running status and sleep status identifier before sleep to non-volatile storage. The monitoring module is used to monitor the data packets received by the edge in real time through a dedicated wake-up protocol detector in the sleep state after the execution of the sleep control command. When a data packet that meets the preset standard is identified, an interrupt signal is triggered to restore the core power supply, the historical running status and sleep status identifier are loaded from non-volatile storage, and the service module wake-up response result is generated.

7. The system according to claim 6, characterized in that, The acquisition module is specifically used for: Collect historical call records of edge services within a preset number of days and operation logs of associated construction equipment, remove outliers through data cleaning, and generate a standardized raw dataset; Based on the construction process, the working condition types are divided, and corresponding working condition labels are added to each record in the standardized original dataset. Typical working condition time periods are determined by clustering the working condition duration, and a time series dataset with working condition labels is generated. Using dynamic sliding window technology, the window size is adaptively adjusted according to the working condition cycle. The time series dataset with working condition labels is segmented, and the mean, variance and peak frequency of the call interval within each window are calculated. Periodic features and abnormal fluctuation features are extracted to generate a feature vector set. The feature vector set is associated with the corresponding working condition label, and dimensionality reduction is performed through principal component analysis to retain more than 95% of the feature contribution rate, thereby generating a business time series feature set with working condition labels.

8. The system according to claim 7, characterized in that, The input module is specifically used for: The connection relationships between various construction processes are analyzed, a directed graph of process dependencies is constructed, the preparation time and connection interval of each process are marked, and a process sequence dependency model is generated. The business time sequence feature set is aligned with the process time sequence dependency model. Through the dynamic time warping algorithm, the call interval in the business time sequence feature set is matched with the connection interval in the process dependency model to generate an aligned feature set with process weights. The aligned feature set is input into a long short-term memory network model that integrates process-dependent weights to predict the business call blank periods within a preset hour in the future and generate an initial list of idle periods. The historical service startup warm-up time is statistically analyzed, and the hibernation start time is calculated backwards from the start time of the initial idle time period list to determine the optimal hibernation window for each idle time period and generate a window candidate set. Conflict detection is performed on the candidate window set, and a start time, end time, and corresponding operating condition label are added to each window to generate a sleep cycle table with time boundaries.

9. A storage medium, characterized in that, The storage medium stores a computer program, wherein the computer program is configured to execute the method of any one of claims 1-5 when it is run.

10. An electronic device comprising a memory and a processor, characterized in that, The memory stores a computer program, and the processor is configured to run the computer program to perform the method of any one of claims 1-5.

Images