Energy-saving-oriented side-end service calling dormancy awakening control method and system

Abstract

The invention discloses an energy-saving-oriented side-end service calling dormancy awakening control method and system, and the method comprises the steps: collecting the historical calling record of side-end service and the operation state data of associated construction equipment, and generating a business time sequence feature set; inputting the service time sequence feature set into a time sequence prediction model, and generating a dormancy periodic table with a time boundary; according to the dormancy periodic table, hardware-level dormancy control is triggered in the idle period, a dormancy control instruction is executed, and meanwhile the service running state before dormancy and a dormancy state identifier are recorded to a nonvolatile memory; and in a dormant state after the dormant control instruction is executed, when a data packet meeting a preset standard is identified, triggering an interrupt signal to recover core power supply, loading a historical operation state and a dormant state identifier from the nonvolatile memory, and generating a service module wake-up response result. By utilizing the embodiment of the invention, hardware-level energy-saving control and rapid state recovery can be realized, and the real-time response capability of service calling is ensured.

Description

Technical Field

[0001] The present invention belongs to the field of edge service technology, and in particular to an energy-saving edge service call sleep and wake-up control method and system. Background Art

[0002] With the rapid development of the Industrial Internet of Things and edge computing, edge services play an important role in the intelligent management of construction equipment. However, edge devices usually run under high load for a long time, resulting in significant energy consumption, especially when they remain active during non-essential operation, resulting in a waste of resources. Traditional energy-saving methods are mainly achieved through dynamic frequency modulation or software hibernation, but it is difficult to accurately match the complex business call patterns in construction scenarios, and it cannot take into account the need for fast wake-up. In addition, the operating status of construction equipment is highly dependent on the process, and existing technologies do not fully combine the working conditions to predict the service idle period, resulting in insufficient timeliness and accuracy of the hibernation strategy. Although hardware-level hibernation can further reduce energy consumption, it lacks support for service status persistence and rapid recovery, which can easily lead to business interruption or response delay. Summary of the Invention

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

[0004] An embodiment of the present application provides an energy-saving edge service call sleep and wakeup control method, the method comprising: Collect historical call records of edge services and the operating status data of related construction equipment. Use a sliding window to extract the periodic characteristics and abnormal fluctuation characteristics of call intervals to generate a business time series feature set with working condition tags. The business time series feature set is input into a time series prediction model that integrates the construction process dependency relationship to predict the business idle period within a preset time period in the future. The optimal sleep window is reversely calculated based on the service startup warm-up time to generate a sleep period table with time boundaries. According to the sleep cycle table, hardware-level sleep control is triggered during the idle period, the sleep control instruction is executed, the core power supply circuit of the service module is cut off through the interrupt controller, the power supply of the wake-up detection circuit is retained, and the service running status and sleep state flag before the sleep state are recorded in non-volatile storage; In the sleep state after executing the sleep control instruction, the data packets received at the edge are monitored in real time through a dedicated wake-up protocol detector. When a data packet that meets the preset standards is identified, an interrupt signal is triggered to restore the core power supply, and the historical operating status and sleep state identifier are loaded from the non-volatile storage to generate a service module wake-up response result.

[0005] Optionally, the historical call records of edge services and the operating status data of related construction equipment are collected, and the periodic characteristics and abnormal fluctuation characteristics of the call intervals are extracted through a sliding window to generate a business time series feature set with working condition tags, including: Collect historical call records of edge services over the past preset days and the operation logs of related construction equipment, remove outliers through data cleaning, and generate a standardized raw data set; Based on the construction process, the working condition types are divided and the corresponding working condition labels are added to each record in the standardized original data set. The typical working condition period is determined by clustering the working condition duration, and a time series data set 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 data set with working condition labels is segmented, and the mean, variance and peak frequency of the call interval in each window are calculated. The periodic characteristics and abnormal fluctuation characteristics are extracted to generate a feature vector set. The feature vector set is associated with the corresponding working condition label, and the dimension is reduced through principal component analysis, retaining more than 95% of the feature contribution rate to generate a business time series feature set with working condition labels.

[0006] Optionally, the business time series feature set is input into a time series prediction model that integrates the construction process dependency, predicting the business idle period within a preset time period in the future, and reversely calculating the optimal sleep window in combination with the service startup warm-up time to generate a sleep period table with time boundaries, including: Sort out the connection relationship between each construction process, build a process dependency directed graph, mark the lead time and connection interval of each process, and generate a process timing dependency model; Align the business timing feature set with the process timing dependency model. Use a dynamic time warping algorithm to match the call intervals in the business timing feature set with the connection intervals in the process dependency model to generate an aligned feature set with process weights. The aligned feature set is input into the fusion process-dependent weighted long short-term memory network model to predict the business call blank periods within the next preset hours and generate an initial idle period list; Count historical service startup warm-up times, combine the start time of the initial idle period list with the reverse calculation of the sleep start time, determine the optimal sleep window corresponding to each idle period, and generate a window candidate set; Conflict detection is performed on the window candidate set, and the start time, end time and corresponding working condition label are added to each window to generate a sleep period table with time boundaries.

[0007] Optionally, triggering hardware-level sleep control during an idle period according to the sleep cycle table, executing a sleep control instruction, cutting off the core power supply circuit of the service module through the interrupt controller, retaining power supply to the wake-up detection circuit, and recording the service running status and sleep state identifier before sleep to non-volatile storage, including: Parse the time boundaries in the sleep period table. When the system time reaches the sleep start time, trigger the hardware-level sleep 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. Compress the service status snapshot and write it to non-volatile storage. Use incremental writes to save only the difference from the previous status. Also record the write time and checksum to generate a status storage record. Generate a sleep control instruction set based on the state storage record. The instruction set includes the core power supply circuit cut-off timing, the wake-up detection circuit power supply parameters and the state storage address, and sends it to the interrupt controller through the bus; When the interrupt controller receives the sleep control instruction set, it cuts off the power supply circuit of the core components of the service module in a timely manner, retaining only the microampere-level power supply of the dedicated wake-up detection circuit, and provides real-time feedback on the power supply switching results and generates a power supply status switching log; The sleep state identifier including the sleep start time, the corresponding window ID and the power supply switching result is written into the non-volatile storage, and the state storage record is associated with the power supply state switching log to complete the sleep triggering.

[0008] Optionally, in the sleep state after executing the sleep control instruction, 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 criteria is identified, an interrupt signal is triggered to restore core power supply, and the historical running status and sleep state identifier are loaded from the non-volatile storage, and a service module wake-up response result is generated, including: In the dormant state, the dedicated wake-up protocol detector enters a low-power monitoring mode, filters irrelevant signals through a preset hardware filter circuit, retains only the data packets in the engineering equipment communication frequency band, captures and temporarily stores received data packet fragments in real time, and generates a queue of data packets to be parsed; Reassemble the fragments in the queue of data packets to be parsed, extract the device ID and command type fields in the packet header, and compare and verify them with the preset standards including the engineering device whitelist and wake-up command signature code. Mark the packets that pass the verification as valid wake-up packets and generate a verification result table; 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, and records the wake-up trigger time and packet characteristics to generate a power recovery log. Read the status storage record and sleep state identifier from the non-volatile storage, load the service status snapshot, restore the process, memory data, and connection, compare the consistency of the power recovery log and the sleep state identifier, and generate a service module wake-up response result including the wake-up time and service recovery status.

[0009] Another embodiment of the present application provides an energy-saving edge service call sleep and wakeup control system, the system comprising: The collection module is used to collect historical call records of edge services and the operating status data of related construction equipment. It uses a sliding window to extract the periodic characteristics and abnormal fluctuation characteristics of call intervals and generate a business time series feature set with working condition tags. An input module is used to input the business time series feature set into a time series prediction model that integrates the construction process dependency, predict the business idle period within a preset time period in the future, reversely calculate the optimal sleep window based on the service startup warm-up time, and generate a sleep period table with time boundaries; A control module, configured 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 power to the wake-up detection circuit, and record the service running status and sleep state identifier before sleep in 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 executing the sleep control instruction. When a data packet that meets the preset standards is identified, an interrupt signal is triggered to restore the core power supply, and the historical operation status and sleep state identification are loaded from the non-volatile storage to generate a service module wake-up response result.

[0010] Yet another embodiment of the present application provides a storage medium, wherein the storage medium stores a computer program, wherein the computer program is configured to execute any of the above methods when run.

[0011] Yet another embodiment of the present application provides an electronic device, comprising a memory and a processor, wherein the memory stores a computer program, and the processor is configured to run the computer program to execute any of the above methods.

[0012] Compared with the existing technology, the present invention provides an energy-saving edge service call sleep and wake-up control method, which collects historical call records of edge services and operating status data of related construction equipment to generate a business timing feature set; inputs the business timing feature set into the timing prediction model to generate a sleep cycle table with time boundaries; according to the sleep cycle table, triggers hardware-level sleep control during idle periods, executes sleep control instructions, and records the service operating status and sleep state identifier before sleep to non-volatile storage; in the sleep state after executing the sleep control instruction, when a data packet that meets the preset standards is identified, an interrupt signal is triggered to restore core power supply, and the historical operating status and sleep state identifier are loaded from the non-volatile storage to generate a service module wake-up response result, thereby achieving hardware-level energy-saving control and rapid state recovery, ensuring real-time response capability of business calls. BRIEF DESCRIPTION OF THE DRAWINGS

[0013] Figure 1 A hardware structure block diagram of a computer terminal that implements an energy-saving edge service call sleep and wakeup control method provided by an embodiment of the present invention; Figure 2 A flowchart of an energy-saving edge service call sleep and wake-up control method provided by an embodiment of the present invention; Figure 3 A structural diagram of an energy-saving edge service call sleep and wake-up control system provided by an embodiment of the present invention. DETAILED DESCRIPTION

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

[0015] The embodiment of the present invention first provides an energy-saving edge service call sleep and wake-up control method, which can be applied to electronic devices such as computer terminals, specifically ordinary computers.

[0016] The following describes it in detail by taking running on a computer terminal as an example. Figure 1 The hardware structure block diagram of a computer terminal that provides an energy-saving edge service call sleep and wake-up control method for an embodiment of the present invention. Figure 1 As shown, the computer device includes a processor, a memory, and a network interface connected via a system bus, wherein the memory may include a non-volatile storage medium and an internal memory.

[0017] The non-volatile storage medium can store an operating system and a computer program. The computer program includes program instructions that, when executed, enable the processor to execute any energy-saving edge service call sleep and wake-up control method.

[0018] The processor is used to provide computing and control capabilities and support the operation of the entire computer equipment.

[0019] The internal memory provides an environment for the operation of computer programs in non-volatile storage media. When the computer program is executed by the processor, the processor can execute any energy-saving edge service call sleep wakeup control method.

[0020] The network interface is used for network communication, such as sending assigned tasks, etc. Those skilled in the art will understand that Figure 1 The structure shown in the figure is only a block diagram of a part of the structure related to the solution of the present application, and does not constitute a limitation on the computer device to which the solution of the present application is applied. The specific computer device may include more or fewer components than shown in the figure, or combine certain components, or have a different component arrangement.

[0021] It should be understood that the processor may be a central processing unit (CPU), other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), field-programmable gate arrays (FPGA), other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor may be a microprocessor or any conventional processor, etc.

[0022] See also Figure 2 The embodiment of the present invention provides an energy-saving edge service call sleep and wake-up control method, which may include the following steps: S201: Collect historical call records of edge services and operating status data of related construction equipment, extract periodic characteristics and abnormal fluctuation characteristics of call intervals through a sliding window, and generate a business time series feature set with working condition tags; Specifically, the historical call records of edge services over the past preset days and the operation logs of related construction equipment can be collected, and outliers can be removed through data cleaning to generate a standardized original data set; Data collection and preliminary processing: The system first sets a preset number of days (for example, 30) and synchronously extracts historical data from the service call log database of edge computing nodes and the operating status monitoring systems of associated construction equipment (such as tower cranes, concrete pump trucks, and rebar processing machines). Call records include the service request timestamp (accurate to the millisecond), call type (e.g., data query, device control command), and response time. Device logs contain the device ID, operating mode (e.g., standby, low load, high load), and sensor readings (e.g., motor current, hydraulic pressure, and temperature). The raw data is matched to the service call and device status with millisecond-level accuracy using a time alignment engine. For example, when a concrete pump truck in "high-pressure pumping" mode issues an "aggregate mix ratio query" service request, the system records the pump truck's oil pressure (in megapascals) and motor speed (in revolutions per minute) at that moment as associated data.

[0023] Outlier cleaning rules: The cleaning process uses a multi-stage filtration mechanism: Physical threshold filtering: Deletes data that exceeds the physical limits of the device (such as records where the tower crane motor current is greater than 150% of the rated value).

[0024] Time series continuity test: Use the sliding Z-score algorithm to detect sudden 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).

[0025] Relevance check: If the device is in the "power off" state but there is a service call record, it is marked as conflicting data.

[0026] The retained dataset after cleaning is standardized: the timestamps are converted to UNIX timestamps (unit: seconds), and numerical parameters (such as oil pressure values) are normalized to the [0,1] interval (the original value is subtracted from the minimum value and then divided by the data range).

[0027] Generate a standardized dataset: The cleaned data is reorganized into a triple structure of "timestamp-service call feature-device status feature". Each record contains: Primary key: a globally unique serial number (such as UUID format).

[0028] Service characteristics: call type code (such as 101 represents device control instructions), response time (unit: milliseconds).

[0029] Equipment characteristics: operating mode code (such as 1-standby, 2-low load), sensor reading collection (such as current value 12.3 amps, oil pressure value 28.5 MPa).

[0030] Finally, a standardized raw data set is generated, sorted in ascending order by timestamp, and stored in Parquet format files in a distributed file system (such as HDFS). Each file contains a single day's data and comes with an MD5 checksum.

[0031] Based on the construction process, the working condition types are divided and the corresponding working condition labels are added to each record in the standardized original data set. The typical working condition period is determined by clustering the working condition duration, and a time series data set with working condition labels is generated. Process-condition mapping modeling: According to the construction organization design document, core processes are divided (such as "foundation excavation", "rebar binding", and "concrete pouring"). Each process is labeled with a working condition type (such as GX for excavation and GJ for rebar processing), and its equipment operating characteristics are clearly defined: Foundation excavation: high vibration frequency of the associated excavator (>50 Hz) and short pauses (average interval <2 minutes).

[0032] Concrete pouring: The pump truck has continuous high pressure (>25MPa) and frequent service calls (average interval <10 seconds).

[0033] Create a process-equipment-service mapping table. For example, in the "Rebar Binding" process, the "Stirrup Angle Calculation" service call of the CNC stirrup bending machine is marked with the working condition tag GJ.

[0034] Dynamic working condition label annotation: Add a working condition label to each record of the normalized original dataset: Rule matching: If the equipment status meets certain process characteristics (such as the pump truck oil pressure is greater than 25MPa and lasts for 5 minutes), it is automatically marked as "HNT" (concrete pouring).

[0035] Manual assisted verification: For data with fuzzy boundaries (such as oil pressure value 15MPa), the labels are manually confirmed through the construction BIM model visualization interface.

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

[0037] Cluster optimization of working period: Use the density clustering algorithm (DBSCAN) to aggregate consecutive time periods with the same working conditions: Input parameters: minimum time period length (MinDuration=10 minutes), maximum interval between adjacent time periods (MaxGap=5 minutes).

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

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

[0040] Using dynamic sliding window technology, the window size is adaptively adjusted according to the working condition cycle. The time series data set with working condition labels is segmented, and the mean, variance and peak frequency of the call interval in each window are calculated. The periodic characteristics and abnormal fluctuation characteristics are extracted to generate a feature vector set. Dynamic window division strategy: The window size is dynamically adjusted according to the working condition type: Short-cycle working conditions (such as equipment debugging, average duration 30 minutes): window size = 5 minutes; Long-cycle working conditions (such as continuous pouring, average duration 4 hours): window size = 30 minutes.

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

[0042] Calculation of features within the window: Calculate the service call records within each window: Mean_Interval: The average value of the time difference between adjacent calls within the window (unit: seconds); Call interval variance (Var_Interval): reflects the degree of interval fluctuation (such as variance > 100 seconds 2 indicates extreme instability).

[0043] Peak frequency (Peak_Freq): The proportion of call intervals less than 1 second (for example, if there are 20 short intervals in 100 calls within the window, Peak_Freq = 0.2).

[0044] At the same time, periodic features are extracted: the dominant frequency is detected by fast Fourier transform (FFT) (for example, a peak of 0.1 Hz indicates a periodic call every 10 seconds).

[0045] Abnormal fluctuation feature extraction: Use the Local Outlier Factor (LOF) algorithm to identify abnormal windows: Input vector: [Mean_Interval, Var_Interval, Peak_Freq] constitutes a three-dimensional feature.

[0046] Abnormal determination: Windows with LOF values ​​greater than 2.0 are marked as abnormal (e.g., a window with a mean of 5 seconds but a variance of 500 seconds 2 ).

[0047] Finally, each window outputs a feature vector in the format of [condition label, window start time, Mean_Interval, Var_Interval, Peak_Freq, dominant frequency, LOF value].

[0048] The feature vector set is associated with the corresponding working condition label, and the dimension is reduced through principal component analysis, retaining more than 95% of the feature contribution rate to generate a business time series feature set with working condition labels.

[0049] Feature-condition associated storage: Feature vectors are grouped and stored by operating condition label (for example, all vectors with label GJ are stored in the same partition). Each vector is associated with the start and end time of the original window and the device ID to which it belongs, forming an operating condition feature cube structure, supporting fast retrieval by operating condition type.

[0050] Principal component analysis dimensionality reduction: For each operating condition group’s characteristic matrix (e.g., the GJ group contains 1000 7-dimensional vectors), execute: Covariance matrix calculation: Analyze the correlation between features (for example, Mean_Interval and Peak_Freq are negatively correlated).

[0051] Eigenvalue decomposition: retain the principal components (PCs) with a cumulative contribution rate of ≥ 95%. For example, the original 7-dimensional features are reduced to 3-dimensional PCs: PC1=0.6×Mean_Interval + 0.3×Var_Interval (contribution rate 70%); PC2=0.5×Peak_Freq - 0.4×dominant frequency (contribution rate 20%); PC3=0.7×LOF value (contribution rate 5%).

[0052] The contribution rate of 95% means that the feature retains 95% of the information of the original data after dimensionality reduction, which is calculated by the ratio of eigenvalues.

[0053] Generate the final feature set: The reduced feature vector is reorganized into the format: [condition label, time window ID, PC1 value, PC2 value, PC3 value]. For example, the window vector of the label GJ is: [GJ, W12345, 1.24, -0.57, 0.33].

[0054] The dataset is stored in a columnar database (e.g., Apache Parquet) with additional features explaining metadata: PC1 stands for “call stability,” PC2 stands for “peak periodicity,” and PC3 stands for “abnormal fluctuation intensity.”

[0055] S202: Input the service time series feature set into a time series prediction model integrated with construction process dependencies to predict service idle periods within a preset time period in the future. Combined with the service startup warm-up time, the optimal sleep window is reversely calculated to generate a sleep period table with time boundaries. Specifically, we can sort out the connection relationship between each construction process, build a process dependency directed graph, mark the lead time and connection interval of each process, and generate a process timing dependency model; The system first extracts a complete list of construction processes from a project management platform (such as a BIM system or construction scheduling database). For concrete pouring, for example, typical processes include rebar tying, formwork installation, embedded parts positioning, concrete pumping, vibration compaction, and curing. By analyzing process start and end timestamps in historical construction logs, logical dependencies between processes are established. For example, formwork installation must begin after at least 80% of rebar tying is complete (a strong dependency), while embedded parts positioning can be performed in parallel with the final 20% of rebar tying (a weak dependency). These dependencies are abstracted as directed graph nodes (DGN), each representing a process. Nodes are connected by edges with arrows, the direction of which indicates the order in which processes are executed. For example, "rebar tying → formwork installation" indicates that the former is a predecessor process (PP) of the latter. Each edge is annotated with two key parameters: Preparation Time (PT) (e.g., formwork installation requires a 30-minute wait for inspection after rebar binding) and Transition Interval (TI) (e.g., formwork deployment requires 10 minutes after inspection). This ultimately forms a Process Dependency Digraph (PDD) containing all process nodes, dependency edges, and time parameter annotations.

[0056] Accurately labeling time parameters relies on multi-source data fusion. Lead time (PT) is calculated by statistically analyzing the average waiting time between adjacent processes in historical construction (e.g., sampling 100 intervals from the end of rebar tying to the start of formwork installation, removing outliers, and taking the average). The connection interval (TI) is calculated based on equipment scheduling rules. For example, if concrete pumping requires waiting for the arrival of a mixer truck, its TI is calculated by adding the average transportation time (e.g., 25 minutes) estimated from the vehicle's GPS trajectory data to the on-site takeover time (e.g., 5 minutes). Processes that can potentially run in parallel (e.g., embedded parts positioning and rebar tying) are represented in the diagram as dashed edges and annotated with the minimum overlap time (MOT; e.g., if the two must run in parallel for at least 15 minutes). Special constraints (e.g., concrete pouring must occur when the temperature is below 30°C on the same day) are converted into environmental dependency nodes (EDNs), connected to the relevant process nodes, and annotated with the valid time window (e.g., 9:00-16:00). The resulting process temporal dependency model (PTDM) is a digital engineering flow chart that includes topology, time parameters, and constraints.

[0057] Model validation was accomplished through discrete event simulation (DES). Temperature data and equipment availability records from a historical construction date (e.g., June 1, 2023) were input, and the PTDM was run to simulate the execution sequence of processes for that day. The simulation results were compared with the actual construction log (e.g., the predicted concrete pumping start time deviated by less than 5 minutes from the actual record). If the deviation exceeded a threshold (e.g., 10%), the PT or TI parameters in the directed graph were adjusted in the opposite direction. After iterative optimization, the PTDM accurately reflects the dynamic temporal relationships between processes. For example, in the summer model, the concrete curing node is automatically associated with the Temperature Sensor Virtual Node (TSVN). When the simulated temperature exceeds 35°C, the curing extension mechanism is triggered (TI increases by 120 minutes). Thus, the PTDM has the dynamic time series prediction capability to adapt to different working conditions.

[0058] Align the business timing feature set with the process timing dependency model. Use a dynamic time warping algorithm to match the call intervals in the business timing feature set with the connection intervals in the process dependency model to generate an aligned feature set with process weights. The Business Time-Series Feature Set (BTFS) contains call interval statistics with work-condition labels (e.g., the mean service call interval for the formwork installation condition is 120 seconds). The Process Time Dependency Model (PTDM) provides theoretical process connection intervals (e.g., the time interval (TI) from formwork installation to concrete pumping is 40 minutes). Due to uncertainties in actual construction (e.g., equipment failures extending the TI), the two require time alignment. This alignment is performed using work-condition time periods as units: all feature vectors for 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 from the process directed graph). This matching utilizes the Dynamic Time Warping (DTW) algorithm, which allows for flexible stretching and compression of the time axis to eliminate timing deviations.

[0059] DTW implementation involves three steps: First, a distance matrix (DM) is constructed, with rows corresponding to the actual BTFS call interval sequence (e.g., [115s, 125s, 118s...]) and columns corresponding to the PTDM theoretical TI sequence ([40min, 40min...]). For each matrix element, the Euclidean distance (ED) between the actual value and the theoretical value is calculated. Next, the optimal warping path (OWP) is found: from the top left corner to the bottom right corner of the matrix, the path with the smallest cumulative distance is selected (if the path allows diagonal movement, it indicates timing synchronization). Finally, the warping distance (WD) is calculated as a matching metric (the smaller the WD, the better the match). For example, if the actual template installation is delayed due to rain, causing the call interval to extend to 180 seconds, DTW will automatically match it to the PTDM node with a TI of 60 minutes under the "rainy day" mode.

[0060] Based on the matching results, a process weight (PW) is generated: PW = 1 / (1 + WD), with a value range of 0-1 (1 indicates a perfect match). PW is added to the original BTFS vector as a new feature. For example, if the actual call interval sequence WD in a window is 0.2 (a high match), PW is assigned 0.83; for another window with WD = 1.2 (a low match), PW is assigned 0.45. This ultimately forms the aligned feature set with process weights (AFS-PW). This process creates a scenario-process weight mapping table (SPWMT) in memory for subsequent prediction model calls.

[0061] The aligned feature set is input into the fusion process-dependent weighted long short-term memory network model to predict the business call blank periods within the next preset hours and generate an initial idle period list; The Long Short-Term Memory Network (LSTM) model employs a three-layer architecture: the input layer receives feature vectors (including PW values) from the AFS-PW, the hidden layer has 128 neurons, and the output layer predicts the probability of service calls at future time points. A key innovation is the use of the process weight (PW) as a weighting coefficient for the attention mechanism. Specifically, the PW participates in the generation of gating signals during the calculation of the LSTM's hidden state. Taking the forget gate as an example, the traditional inputs are the current feature x_t and the previous state h_{t-1}. This model adds a PW factor, formulated as forget gate strength ∝ PW × x_t (a higher PW indicates a stronger influence of historical process features). For example, when PW = 0.9 (indicating a close match between the current working conditions and the PTDM), the model will place greater trust in the process interval patterns predicted by the PTDM.

[0062] The model is trained using historical AFS-PW data and validated using a sliding prediction method. This involves taking 24 consecutive hours of data, with the first 12 hours as input, and predicting the service call status (0 / 1 binary labels) for every 5-minute interval for the next 12 hours. The loss function uses Focal Loss (FL), which weights difficult examples (such as calls due to sudden equipment failures). After training, the prediction process is deployed: The model inputs AFS-PW data from the previous 6 hours (including the most recent PW) and outputs the call probability value (CPV) (a continuous value between 0 and 1) for each 5-minute window within a preset future timeframe (e.g., 8 hours). A CPV < 0.05 (configurable threshold) is marked as a potential idle slot (PIS).

[0063] Idle Slot Merging Optimization: Consecutive PISs are merged into a single idle slot (e.g., three consecutive 5-minute PISs are merged into a 15-minute slot). Invalid segments are eliminated: Slots shorter than the minimum hibernation time (MHT = 3 minutes) are discarded. Finally, an Initial Idle Slot List (IISL) is generated. Each record includes a start time (ST), end time (ET), and confidence level (CL = 1-CPV). For example, a prediction 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.

[0064] Count historical service startup warm-up times, combine the start time of the initial idle period list with the reverse calculation of the sleep start time, determine the optimal sleep window corresponding to each idle period, and generate a window candidate set; The service warm-up time (SWT) is statistically calculated through the monitoring system logs: the time consumption from receiving the wake-up instruction to the service being fully ready (such as loading the in-memory data and establishing the database connection). Extract the last 100 startup records, and calculate the dynamic warm-up time (DWT) = the 90th percentile time consumption (ensuring it is sufficient for 90% of the scenarios) after excluding the outliers (such as those exceeding 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: the hibernation start time (HST) = the start time of the idle period (ST) - DWT - the 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.

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

[0066] Energy consumption optimization is performed when generating the window candidate set (WCS): Calculate the estimated energy saving (EES) for each OHW = (WD - DWT) × the power in the hibernation state. Preferentially select the window with EES > 1000 joules (configurable). For example, for an OHW with WD = 25 minutes and the power in the hibernation state of 5 watts, then EES = (1500s - 45s) × 5J / s = 7275 joules. Finally, the WCS is stored sorted by HST, and each entry contains: [window ID, HST, HET, EES, associated operating condition label].

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

[0068] Conflict Detection (CD) includes three types of conflict handling: 1) Time overlap conflict: Check whether any two windows [HS T1, HE T1] and [HST2, HET2] in the WCS overlap (HST1 < HET2 and HST2 < HET1). If they overlap, the larger EES window is retained first; 2) Scenario switching conflict: If adjacent windows have different working condition labels (e.g., window A is "rebar binding" and window B is "concrete curing"), and the interval is less than the working condition switching buffer time (Scenario Transition Buffer Time, STBT = 5 minutes), the windows are merged and marked as a mixed working condition; 3) Resource occupancy conflict: Query the device calendar (e.g., the vibrator charging period is 14:00-14:30). If the OHW window overlaps with the device occupancy period, the window is eliminated.

[0069] After the conflict is resolved, metadata is added to each window: Start Boundary Time (SBT) = HST (accurate to seconds); End Boundary Time (EBT) = HET; Scenario Tag (ST) is taken from the scenario type of the associated idle period; Additional execution policy parameters: Wake-up Advance Time (WAT) = DWT + SM (54 seconds in the previous example); Maximum Wake-up Delay (MWD) = 2 seconds (hardware guarantee indicator).

[0070] Generate a Hibernation Schedule with Time Boundaries (HSTB) in JSON format, including: { "schedule_id": "SCH_20230720", "windows": [ { "window_id": "WIN_001", "start_time": "2023-07-20 13:59:06", "end_time": "2023-07-20 14:25:00", "scenario_tag": "template_installation", "wake_up_advance": 54, "energy_saving": 7275 }, / / Other windows... ] }.

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

[0072] S203, triggering hardware-level sleep control during an idle period according to the sleep cycle table, executing the sleep control instruction, disconnecting the core power supply circuit of the service module through the interrupt controller, retaining power to the wake-up detection circuit, and recording the service running status and sleep state flag before sleep in non-volatile storage; Specifically, the time boundary in the sleep period table can be parsed. When the system time reaches the sleep start time, the hardware-level sleep 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 to generate a service status snapshot. The Sleep Cycle Table (SCT) is a structured data table that clearly identifies the start time (ST), end time (ET) of each sleep window, and associated working condition tags (such as "concrete pouring interval" or "rebar binding preparation period"). The Central Sleep Scheduler (CSS) continuously monitors the System Clock (SC). When the difference between the SC's current timestamp (CT) and the ST of a sleep window in the SCT is less than a preset threshold (for example, 10 seconds), the CSS triggers the hardware-level sleep preparation process. This process first collects the real-time operating status of the service module through the Status Detection Interface (SDI) provided by the operating system kernel. The SDI polls the service module's key indicators at a millisecond frequency: Process ID Set (PIDS): Lists the IDs of all active service processes (e.g., PID 8080 for the Apache service, PID 3306 for the database service). Memory Occupation Map (MOM): records the real-time usage of each process's heap memory (HM), stack memory (SM), and shared memory (SHM) (in MB). Data Connection State (DCS): includes the number of TCP / UDP connections (such as the current number of database connections maintained is 20), the socket descriptor list (such as FD 1024-1040), and the network session key (SessionKey, SK).

[0073] The CSS encapsulates this data into a Service State Snapshot (SSS), storing it in a mixed binary and text format. It also adds a timestamp (SST) and a cyclic redundancy check code (CRCC) to ensure integrity. For example, during the "nighttime equipment inspection window," the CSS might capture an SSS containing the following: PIDs {1102, 1105}, memory usage {1102: 45MB, 1105: 32MB}, and a database connection pool status of "idle:15."

[0074] Compress the service status snapshot and write it to non-volatile storage. Use incremental writes to save only the difference from the previous status. Also record the write time and checksum to generate a status storage record. After the service state snapshot (SSS) is generated, the storage optimization phase begins. First, the Lightweight Compression Engine (LCE) is invoked to compress the SSS in real time using the LZ4 algorithm, 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 (FRAM) or flash EEPROM, using the Delta Write Strategy (DWS). The core mechanisms of DWS are: When writing for the first time, save the full SSS (e.g., size 50KB); Subsequent writes only record the difference (Delta, DL) from the previous snapshot. For example, only the changed process memory value (such as the memory of PID 1105 changes from 32MB to 33MB) or the newly added connection status are updated. Difference detection is achieved through the Bitmap Comparison Algorithm (BCA), which only marks the changed Data Block Address (DBA).

[0075] When writing to NVS, the system also records key metadata: Write Time (WT): Greenwich Mean Time (GMT) accurate to milliseconds; Checksum Value (CV): A 64-character unique identification code generated using the SHA-256 hash algorithm; Storage Address Pointer (SAP): points to the physical location of CS in NVS (such as 0xFE00-0xFF20).

[0076] The above metadata and CS together form a State Storage Record (SSR). For example, a write generates an SSR with the following data: WT=2025-04-11 02:00:00.123, CV="a1b2c3...", SAP=0xDEAD, DL_SIZE=2KB (only two memory block changes).

[0077] Generate a sleep control instruction set based on the state storage record. The instruction set includes the core power supply circuit cut-off timing, the wake-up detection circuit power supply parameters and the state storage address, and sends it to the interrupt controller through the bus; 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 instructions: Core Power Cut Sequence (CPS): Step-by-step power-off strategy: The first step is to shut down the main CPU (delay 100 milliseconds), the second step is to disconnect the memory power supply (delay 50 milliseconds), and the third step is to disconnect the peripheral bus (such as PCIe) (delay 30 milliseconds); Timing parameters include the delay value (DV) and voltage drop threshold (VDT) of each step, such as 3.3V to 0.8V. Wake-up Circuit Sustained Parameters (WCSP): Circuit scope of power maintenance: limited to the wake-up protocol detector (WPD) and its associated RF receiver module; Supply voltage: 3.3V (nominal ±5%); Maximum allowable current: 200 μA; State Storage Address (SSA): Directly references the SAP value in the SSR (such as 0xDEAD) for quick data location during wakeup.

[0078] SCIS uses a low-power serial bus (such as I 2 The data is transmitted to the interrupt controller (IC) via C or SPI (Serial Peripheral Interface). Manchester Encoding (ME) is used for bus transmission 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, a Type field of "0x01" represents a CPCS instruction, and a Length field of "0x0C" indicates that the following 12 bytes contain three sets of delay parameters (4 bytes each).

[0079] When the interrupt controller receives the sleep control instruction set, it cuts off the power supply circuit of the core components of the service module in a timely manner, retaining only the microampere-level power supply of the dedicated wake-up detection circuit, and provides real-time feedback on the power supply switching results and generates a power supply status switching log; After receiving the SCIS, the interrupt controller (IC) initiates the hardware-level power-off process. The IC's built-in instruction parser (IP) decodes the CPCS timing and drives multiple power control relays (PCRs) to perform a step-by-step power-off: Main CPU power off: The IC sends a "PWRDOWN" signal to the CPU power management chip (such as TI TPS65261), triggering the undervoltage lockout (UVLO) mechanism, which reduces the core voltage (V_CORE) from 1.2V to 0V within 100ms. Memory power off: By I 2The C bus is equipped with a DDR power controller (such as ISL95812), which shuts down the memory power rail (V_DDR) and delays it by 50 milliseconds to ensure data silence. Peripheral bus power off: Control the MOSFET switch (such as AO3400) to disconnect the 12V power supply (V_PCIE) of the PCIe slot, with a delay of 30 milliseconds.

[0080] During power-off, the IC strictly maintains the power supply to the Wake-up Detection Circuit (WDC): Power source: independent low-dropout linear regulator (LDO, such as MCP1700); Power supply specifications: 3.3V±0.1V, current limited to within 200 microamperes (the measured value is usually 150 microamperes).

[0081] The IC monitors the voltage and current of each power supply circuit in real time and generates a Power State Switch Log (PSSL) to record: The actual delay of each step (e.g., a CPU power outage takes 102 milliseconds); Voltage drop curve sampling points (e.g., recording V_CORE values ​​every 5 milliseconds); Abnormal event flag (such as "memory power supply residual 0.5V").

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

[0083] The sleep state identifier including the sleep start time, the corresponding window ID and the power supply switching result is written into the non-volatile storage, and the state storage record is associated with the power supply state switching log to complete the sleep triggering.

[0084] 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 the dedicated area of ​​the non-volatile storage (NVS) (address 0xF000-0xF0FF). Its data structure contains: Sleep Start Time (SST): The precise timestamp taken from the system clock (format: YYYYMMDDHHMMSSmmm); Sleep Window ID (SWID): refers to the unique identifier in the Sleep Cycle Table (SCT) (e.g., "SW_20250411_0200"). Power Switch Result (PSR): A simplified summary of PSSL key features, including: a list of components that were successfully powered off (such as "CPU: OK, DDR: OK"); the measured power supply value of the wake-up circuit (such as "WDC_VOLTAGE: 3.28V"); and an exception code (if any, such as "ERR_DDR_RESIDUAL: 0.2V").

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

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

[0087] S204, in the sleep state after executing the sleep control instruction, the data packets received at the edge are monitored in real time through 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 operating status and sleep state identifier are loaded from the non-volatile storage to generate a service module wake-up response result.

[0088] Specifically, in the dormant state, the dedicated wake-up protocol detector enters a low-power monitoring mode, filters irrelevant signals through a preset hardware filter circuit, retains only data packets in the engineering equipment communication frequency band, captures and temporarily stores received data packet fragments in real time, and generates a queue of data packets to be parsed; Low power monitoring mode activated: When the service module's core power is cut off, the dedicated wake-up protocol detector (DWPD) automatically switches to low-power monitoring mode (LPMM). This mode shuts down non-essential internal detector functions (such as the high-speed clock tree and multi-channel ADCs), leaving only the basic RF receive chain and signal pre-processing circuitry operational. The detector's operating voltage is reduced from the standard 3.3 volts (V) to 1.2 volts (V), and current consumption is reduced from milliamperes (mA) to microamperes (μA), with a typical value of 15 μA. During this time, the DWPD's RF front-end (RFFE) continuously scans the designated engineering equipment communication band (such as the 400-450 MHz industrial wireless band or the 2.4 GHz Zigbee band), but its receive sensitivity is adjusted to -85 decibel milliwatts (dBm), lower than the -110 dBm in active mode, to further reduce power consumption.

[0089] Hardware filter circuit signal filtering: All raw signals entering the RF front end first pass through the preset hardware filter circuit (HFC). This circuit consists of two stages: The first-stage bandpass filter (BPF) uses a surface acoustic wave filter (SAWF) with a center frequency set to the target frequency band (e.g., 433 MHz) and a bandwidth of 2 MHz. It attenuates out-of-band signals by at least 40 decibels (dB). For example, it completely shields common mobile phone 4G signals (1.8 GHz) or Wi-Fi signals (5 GHz).

[0090] The second-stage digitally tunable filter (DTF) uses a finite impulse response (FIR) filter algorithm implemented on a field-programmable gate array (FPGA) to dynamically adjust the passband based on the current working condition. For example, in the "concrete pouring" working condition, only the characteristic frequencies of packets with the device ID "CEM-MIXER-XX" are passed. After two stages of filtering, only signals within the valid frequency band are retained and sent to the packet inspection module.

[0091] Packet Capture and Queue Generation: The packet detection module uses a sliding window capture mechanism (SWCM): When the signal strength exceeds -80 decibel milliwatts (dBm) and lasts for 0.5 milliseconds (ms), it is determined to be the start of a valid data packet; The signal is sampled at a rate of 1 megabit per second (Mbps), and each data packet is divided into fixed 128-byte fragments. A timestamp (TS) and a signal strength tag (RSSI Tag, RT) are added.

[0092] The fragments are temporarily stored in a circular buffer (CB) with a depth of 8. When the buffer is full or there is continuous silence for more than 5 milliseconds (ms), the buffer contents are packaged into packet units (PUs), which are then added with a header check sequence (HCS) and 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 PUs. If the queue overflows, the oldest PU is discarded.

[0093] Reassemble the fragments in the queue of data packets to be parsed, extract the device ID and command type fields in the packet header, and compare and verify them with the preset standards including the engineering device whitelist and wake-up command signature code. Mark the packets that pass the verification as valid wake-up packets and generate a verification result table; Packet reassembly and field extraction: The Verification Engine (VE) takes a packet unit (PU) from the head of the PPPPQ and performs reassembly: Segment sorting: 128-byte segments are concatenated in sequence based on the timestamp (TS) and internal sequence number (SN); Packet header parsing: Locate the packet header start flag (fixed to 0xAA55) and extract key fields according to the protocol format: 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"; Integrity check: 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 check.

[0094] Preset standard dynamic loading: Preset Criteria (PC) are stored in the detector's read-only memory (ROM) and contain two key types of data: Engineering Device Whitelist (EDWL): This stores authorized device IDs and their hash values ​​(e.g., SHA-256 digests) in a hash table format. For example, a key-value pair might look like: Key="CEM-MIXER"→Value=0x9f86d081...; Wake-up Command Feature Code (WCFC): Defines the bit pattern for a valid wake-up command. For example, when the command type is 0x01 (startup command), the packet length must be 64 bytes and bytes 32-33 must be 0x10FF.

[0095] Whitelists and signatures can be updated through non-volatile storage, and digital signatures must be verified during updates.

[0096] Comparison verification and result marking: The verification process is performed in two levels: Whitelist verification: Calculate the hash value of the extracted device ID field (DIDF) and query the engineering device whitelist (EDWL). If it matches, it will proceed to the next level, otherwise it will be discarded; Signature Verification: Compare the Command Type Field (CTF) and the packet payload content with the Wake-Up Command Signature Code (WCFC) bit by bit. For example, if the CTF is 0x01, verify that the two bytes at offset 32 ​​of the payload are 0x10FF.

[0097] Data packets that pass both levels of verification are marked as valid wake-up packets (VWPs), 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 memory structure with 8 rows, each containing the verification status (1 byte), timestamp (4 bytes), and device ID (6 bytes). The oldest record is overwritten if it overflows.

[0098] 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, and records the wake-up trigger time and packet characteristics to generate a power recovery log. Interrupt signal triggering mechanism: The Dedicated Wake-up Protocol Detector (DWPD) scans the Verification Result Table (VRT) in real time. When it detects that the verification status of any row is "valid" (status value = 0x01): Immediately freeze the current data packet processing pipeline and save the scene to the register file; Read the device ID (DID) and command type (CT) of the valid wake-up packet (VWP) from the VRT and generate an interrupt feature code (IFC) in the format of DID (6 bytes) + CT (1 byte) + timestamp (4 bytes). A high-level interrupt signal with a fixed pulse width of 50 microseconds (μs) is sent to the Power Management Unit (PMU) via the wake-up pin (WP, hardware defined as GPIO12). At the same time, the interrupt feature code (IFC) is written to the 16-bit data bus (DB) in parallel.

[0099] Power restoration preset timing: After receiving the interrupt signal, the power management unit (PMU) executes the four-level power restoration sequence (PRS): T0 phase (0-5 milliseconds): The enable pin of the core voltage regulator (CVR) is activated, but the output remains off; T1 stage (5-10 milliseconds): Slowly increase the core voltage to 1.0 volts (V) at a slope of 0.1 volts (V) / millisecond (ms) to prevent inrush current; T2 stage (10-15 milliseconds): Release the clock generator (CG) reset and output the initial low-frequency clock (such as 1 MHz); T3 phase (15-20 milliseconds): The core voltage is raised to a nominal 3.3 volts (V), the clock is switched to full speed (e.g., 100 MHz), and a "Power Ready Signal" (PRS) is sent to the detector.

[0100] 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.

[0101] Power restoration log generation: When the T0 phase starts, the PMU starts recording key parameters: Wake-up Trigger Time (WTT): taken from the real-time clock (RTC), with an accuracy of ±1 millisecond (ms); Packet Features (PF): directly stores the received Interrupt Feature Code (IFC); Power Parameters (PP): including the actual voltage value at each stage (sampling rate 1 kHz), peak current (PC), and timing deviation (TD).

[0102] The above data is packaged into a power restoration log (PRL) in binary format and written to the PMU's built-in 512-byte non-volatile cache (NVC). After the log is generated, DMA is triggered to transfer it to the main non-volatile storage.

[0103] Read the status storage record and sleep state identifier from the non-volatile storage, load the service status snapshot, restore the process, memory data, and connection, compare the consistency of the power recovery log and the sleep state identifier, and generate a service module wake-up response result including the wake-up time and service recovery status.

[0104] Hibernation data loading and verification: After the core power supply of the service module is stable, the bootloader executes: Locating the storage record: Based on the pointer (PT) in the Hibernation State Identifier (HSI), the state storage record (SSR) and the HSI (HSI body) are searched in the non-volatile storage (NVS). Data integrity check: Calculate the CRC-32 checksum 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.

[0105] Incremental data reconstruction: If the SSR is incremental storage (recording the difference from the previous state), you need to load the base image (BI) and apply the difference patch (DP) to reconstruct the complete service state snapshot (SSS).

[0106] State recovery and system reconstruction: After the OS Kernel takes over, restore the system according to the snapshot contents: Process recovery: Rebuild 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. Memory restore: Writes the memory page data (MPD) in the snapshot back to physical memory according to the Virtual Address Mapping Table (VAMT), marking dirty pages for writeback.

[0107] Connection reestablishment: Network connection: Send TCP Keep-Alive packets to maintain the session based on the TCP 4-tuple (source IP, source port, destination IP, destination port) and sequence number (SN) in the snapshot; Device connection: Send a "Status Sync Request" (SSR) to the associated construction equipment. If confirmation is received, the I / O channel will be restored.

[0108] Wake-up response result generation: After the service module is fully restored, the diagnostic module (DM) performs the following operations: Consistency comparison: Extract the wakeup trigger time (WTT) from the power recovery log (PRL) and the hibernation start time (HST) from the hibernation state identifier (HSI) to calculate the actual hibernation duration (AHD). Compare the AHD with the planned duration (PD) in the hibernation period table. If the deviation exceeds 10%, an anomaly is flagged.

[0109] Service status check: Process survival rate: Count the number of recovered processes / 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 command response delay of construction equipment (for example, a response within 200 milliseconds is considered normal).

[0110] Generate response results: The summary data is the Service Module Wake-up Response Result (SMWRR), 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 the AHD deviation value and detailed results of each check item.

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

[0112] It can be seen that the historical call records of edge services and the operating status data of related construction equipment are collected to generate a business timing feature set; the business timing feature set is input into the timing prediction model to generate a sleep cycle table with time boundaries; according to the sleep cycle table, hardware-level sleep control is triggered during the idle period, and the sleep control instruction is executed. At the same time, the service running status and sleep state identifier before sleep are recorded to non-volatile storage; in the sleep state after executing the sleep control instruction, when a data packet that meets the preset standards is identified, an interrupt signal is triggered to restore the core power supply, and the historical running status and sleep state identifier are loaded from the non-volatile storage, and the service module wake-up response result is generated, thereby realizing hardware-level energy-saving control and rapid state recovery, ensuring the real-time response capability of business calls.

[0113] Another embodiment of the present invention provides an energy-saving edge service call sleep and wake-up control system, see Figure 3 , the system may include: The collection module 301 is used to collect historical call records of edge services and the operating status data of related construction equipment. It extracts the periodic characteristics and abnormal fluctuation characteristics of call intervals through a sliding window to generate a business time series feature set with working condition tags. Input module 302 is used to input the business time series feature set into a time series prediction model integrated with the construction process dependency, predict the business idle period within a preset time period in the future, reversely calculate the optimal sleep window based on the service startup warm-up time, and generate a sleep period table with time boundaries; The control module 303 is configured 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 power to the wake-up detection circuit, and record the service running status and sleep state flag before sleep in non-volatile storage; 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 instruction. When a data packet that meets the preset standards is identified, an interrupt signal is triggered to restore the core power supply, and the historical operation status and sleep state identification are loaded from the non-volatile storage to generate a service module wake-up response result.

[0114] An embodiment of the present invention further provides a storage medium storing a computer program, wherein the computer program is configured to execute the steps of any one of the above method embodiments when running.

[0115] An embodiment of the present invention further provides an electronic device, comprising 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 one of the above method embodiments.

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

[0117] The above describes in detail the structure, features and effects of the present invention based on the embodiments shown in the drawings. The above is only a preferred embodiment of the present invention, but the scope of implementation of the present invention is not limited to what is shown in the drawings. Any changes made in accordance with the concept of the present invention, or modifications to equivalent embodiments with equivalent changes, which do not exceed the spirit covered by the description and drawings, should be within the scope of protection of the present invention.

Claims

1. A method for controlling the sleep and wakeup of edge service calls for energy saving, characterized in that: The method comprises: Collect historical call records of edge services and the operating status data of related construction equipment. Use a sliding window to extract the periodic characteristics and abnormal fluctuation characteristics of call intervals to generate a business time series feature set with working condition tags. The business time series feature set is input into a time series prediction model that integrates the construction process dependency relationship to predict the business idle period within a preset time period in the future. The optimal sleep window is reversely calculated based on the service startup warm-up time to generate a sleep period table with time boundaries. According to the sleep cycle table, hardware-level sleep control is triggered during the idle period, the sleep control instruction is executed, the core power supply circuit of the service module is cut off through the interrupt controller, the power supply of the wake-up detection circuit is retained, and the service running status and sleep state flag before the sleep state are recorded in non-volatile storage; In the sleep state after executing the sleep control instruction, the data packets received at the edge are monitored in real time through a dedicated wake-up protocol detector. When a data packet that meets the preset standards is identified, an interrupt signal is triggered to restore the core power supply, and the historical operating status and sleep state identifier are loaded from the non-volatile storage to generate a service module wake-up response result.

2. The method according to claim 1, characterized in that The historical call records of edge services and the operating status data of related construction equipment are collected, and the periodic characteristics and abnormal fluctuation characteristics of the call intervals are extracted through a sliding window to generate a business time series feature set with working condition tags, including: Collect historical call records of edge services over the past preset days and the operation logs of related construction equipment, remove outliers through data cleaning, and generate a standardized raw data set; Based on the construction process, the working condition types are divided and the corresponding working condition labels are added to each record in the standardized original data set. The typical working condition period is determined by clustering the working condition duration, and a time series data set 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 data set with working condition labels is segmented, and the mean, variance and peak frequency of the call interval in each window are calculated. The periodic characteristics and abnormal fluctuation characteristics are extracted to generate a feature vector set. The feature vector set is associated with the corresponding working condition label, and the dimension is reduced through principal component analysis, retaining more than 95% of the feature contribution rate to generate a business time series feature set with working condition labels.

3. The method according to claim 2, characterized in that The business time series feature set is input into the time series prediction model integrated with the construction process dependency relationship to predict the business idle period within a preset time period in the future, and the optimal sleep window is reversely calculated based on the service startup warm-up time to generate a sleep period table with time boundaries, including: Sort out the connection relationship between each construction process, build a process dependency directed graph, mark the lead time and connection interval of each process, and generate a process timing dependency model; Align the business timing feature set with the process timing dependency model. Use a dynamic time warping algorithm to match the call intervals in the business timing feature set with the connection intervals in the process dependency model to generate an aligned feature set with process weights. The aligned feature set is input into the fusion process-dependent weighted long short-term memory network model to predict the business call blank periods within the next preset hours and generate an initial idle period list; Count historical service startup warm-up times, combine the start time of the initial idle period list with the reverse calculation of the sleep start time, determine the optimal sleep window corresponding to each idle period, and generate a window candidate set; Conflict detection is performed on the window candidate set, and the start time, end time and corresponding working condition label are added to each window to generate a sleep period table with time boundaries.

4. The method according to claim 3, characterized in that The method includes triggering hardware-level sleep control during an idle period according to the sleep cycle table, executing a sleep control instruction, cutting off the core power supply circuit of the service module through the interrupt controller, retaining the power supply of the wake-up detection circuit, and recording the service running status and sleep status identifier before sleep in non-volatile storage, including: Parse the time boundaries in the sleep period table. When the system time reaches the sleep start time, trigger the hardware-level sleep 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. Compress the service status snapshot and write it to non-volatile storage. Use incremental writes to save only the difference from the previous status. Also record the write time and checksum to generate a status storage record. Generate a sleep control instruction set based on the state storage record. The instruction set includes the core power supply circuit cut-off timing, the wake-up detection circuit power supply parameters and the state storage address, and sends it to the interrupt controller through the bus; When the interrupt controller receives the sleep control instruction set, it cuts off the power supply circuit of the core components of the service module in a timely manner, retaining only the microampere-level power supply of the dedicated wake-up detection circuit, and provides real-time feedback on the power supply switching results and generates a power supply status switching log; The sleep state identifier including the sleep start time, the corresponding window ID and the power supply switching result is written into the non-volatile storage, and the state storage record is associated with the power supply state switching log to complete the sleep triggering.

5. The method according to claim 4, characterized in that In the sleep state after executing the sleep control instruction, the dedicated wake-up protocol detector monitors the data packets received by the edge in real time. 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 state identifier are loaded from the non-volatile storage, and a service module wake-up response result is generated, including: In the dormant state, the dedicated wake-up protocol detector enters a low-power monitoring mode, filters irrelevant signals through a preset hardware filter circuit, retains only the data packets in the engineering equipment communication frequency band, captures and temporarily stores received data packet fragments in real time, and generates a queue of data packets to be parsed; Reassemble the fragments in the queue of data packets to be parsed, extract the device ID and command type fields in the packet header, and compare and verify them with the preset standards including the engineering device whitelist and wake-up command signature code. Mark the packets that pass the verification as valid wake-up packets and generate a verification result table; 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, and records the wake-up trigger time and packet characteristics to generate a power recovery log. Read the status storage record and sleep state identifier from the non-volatile storage, load the service status snapshot, restore the process, memory data, and connection, compare the consistency of the power recovery log and the sleep state identifier, and generate a service module wake-up response result including the wake-up time and service recovery status.

6. An energy-saving edge service call sleep and wake-up control system, characterized in that: The system comprises: The collection module is used to collect historical call records of edge services and the operating status data of related construction equipment. It uses a sliding window to extract the periodic characteristics and abnormal fluctuation characteristics of call intervals and generate a business time series feature set with working condition tags. An input module is used to input the business time series feature set into a time series prediction model that integrates the construction process dependency, predict the business idle period within a preset time period in the future, reversely calculate the optimal sleep window based on the service startup warm-up time, and generate a sleep period table with time boundaries; A control module, configured 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 power to the wake-up detection circuit, and record the service running status and sleep state identifier before sleep in 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 executing the sleep control instruction. When a data packet that meets the preset standards is identified, an interrupt signal is triggered to restore the core power supply, and the historical operation status and sleep state identification are loaded from the non-volatile storage to generate a service module wake-up response result.

7. The system according to claim 6, characterized in that The acquisition module is specifically used to: Collect historical call records of edge services over the past preset days and the operation logs of related construction equipment, remove outliers through data cleaning, and generate a standardized raw data set; Based on the construction process, the working condition types are divided and the corresponding working condition labels are added to each record in the standardized original data set. The typical working condition period is determined by clustering the working condition duration, and a time series data set 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 data set with working condition labels is segmented, and the mean, variance and peak frequency of the call interval in each window are calculated. The periodic characteristics and abnormal fluctuation characteristics are extracted to generate a feature vector set. The feature vector set is associated with the corresponding working condition label, and the dimension is reduced through principal component analysis, retaining more than 95% of the feature contribution rate to generate 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: Sort out the connection relationship between each construction process, build a process dependency directed graph, mark the lead time and connection interval of each process, and generate a process timing dependency model; Align the business timing feature set with the process timing dependency model. Use a dynamic time warping algorithm to match the call intervals in the business timing feature set with the connection intervals in the process dependency model to generate an aligned feature set with process weights. The aligned feature set is input into the fusion process-dependent weighted long short-term memory network model to predict the business call blank periods within the next preset hours and generate an initial idle period list; Count historical service startup warm-up times, combine the start time of the initial idle period list with the reverse calculation of the sleep start time, determine the optimal sleep window corresponding to each idle period, and generate a window candidate set; Conflict detection is performed on the window candidate set, and the start time, end time and corresponding working condition label are added to each window to generate a sleep period 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 according to any one of claims 1 to 5 when executed.

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

Images