Elevator no-load monitoring method based on AI computing power analysis, RUL prediction and big data optimization

Abstract

The invention relates to the technical field of elevator operation safety monitoring, and discloses an elevator no-load monitoring method based on AI computing power analysis, RUL prediction and big data optimization, and the method comprises the following steps: S1, a system initialization step; s2, a data acquisition step; s3, a computing power analysis step; s4, a step of AI reasoning and RUL prediction; s5, a monitoring period prediction step; s6, executing a no-load test; s7, a score calculation and optimization step; s8, a data uploading and big data optimization step; and S9, a manual intervention step. According to the elevator no-load monitoring method based on AI computing power analysis, RUL prediction and big data optimization, by arranging a dynamic computing power distribution mechanism and an edge computing RTOS operating system, self-adaptive resource scheduling is achieved, and particularly, according to the idle computing power of edge equipment (if a high-precision AI model is selected when the idle computing power is larger than 50%, otherwise a lightweight model is selected), the optimal scheduling of the edge equipment is achieved. And in combination with task priority scheduling of an RTOS kernel layer, the real-time requirement is ensured.

Description

Technical Field

[0001] This invention relates to the field of elevator operation safety monitoring technology, specifically to an elevator no-load monitoring method based on AI computing power analysis, RUL prediction, and big data optimization. Background Technology

[0002] Elevator cars are widely driven by wire rope traction. Only one car can be installed in a shaft. Elevators with single-car operation mode can still meet the needs of low-rise buildings and places with low traffic.

[0003] AI computing power analysis technology dynamically allocates computing resources to ensure real-time execution of monitoring tasks even with limited edge device computing power. This adaptive computing power allocation mechanism enables even existing elevator motherboard chips with limited computing power to meet the needs of intelligent upgrades. RUL prediction technology establishes accurate equipment status prediction models through in-depth analysis of historical monitoring data, significantly improving the accuracy and reliability of monitoring results. Dynamic adjustment of the monitoring cycle based on trend analysis ensures monitoring effectiveness while avoiding resource waste. Big data optimization technology continuously optimizes edge algorithm models through cloud-based collaborative analysis, enabling continuous self-improvement of the monitoring system. This optimization mechanism ensures that the system can adapt to changes in different operating environments and equipment statuses.

[0004] According to the invention patent with Chinese patent application number 202011465086.7, the method for dynamic monitoring of the applied load of multi-car intelligent parallel elevators can realize the dynamic monitoring of the applied load of multi-car parallel elevators. However, this method relies on a load test mode, which has high social compliance costs and is extremely demanding on hardware computing power, making it difficult to adapt to the intelligent upgrade needs of existing elevators. Therefore, it is necessary to propose an elevator no-load monitoring method based on AI computing power analysis, RUL prediction and big data optimization to solve the above-mentioned problems. Summary of the Invention

[0005] (a) Technical problems to be solved

[0006] To address the shortcomings of existing technologies, this invention provides an elevator no-load monitoring method based on AI computing power analysis, RUL prediction, and big data optimization. This method significantly reduces elevator testing compliance costs and effectively compensates for the computing power limitations of existing elevator motherboard chips.

[0007] (II) Technical Solution

[0008] To achieve the above objectives, the present invention provides the following technical solution: a method for monitoring elevator no-load based on AI computing power analysis, RUL prediction, and big data optimization, comprising the following steps:

[0009] S1. System Initialization Steps: Start the embedded edge computing RTOS operating system, perform hardware initialization, RTOS kernel initialization, and task scheduling initialization. Task scheduling includes high-priority data acquisition tasks, medium-priority AI inference tasks, and low-priority resource monitoring tasks to ensure real-time performance. Hardware initialization needs to be specific: initialize the CPU (e.g., ARM Cortex-M7), clock, memory, and elevator motherboard peripherals (encoder, communication ports), configure register addresses (e.g., speed register 0x01, current register 0x02), and fix the 100ms sampling period. Hardware reliability verification includes three layers of verification:

[0010] S2. Data Acquisition Steps: Configure and fix the register address for 100 milliseconds through the elevator motherboard chip to collect elevator running sequence data in real time, including speed, current, and torque parameters. Perform data preprocessing to extract time-domain and frequency-domain features. Data preprocessing includes data cleaning, noise filtering, and feature extraction. Feature extraction covers time-domain mean, variance, and frequency-domain FFT transform frequency. Data acquisition relies on the "edge data collection submodule": synchronously collect data from multiple physical quantity sensors (such as encoders and accelerometer chips) through the UART / EMAC interface, and integrate anti-interference filtering algorithms (such as digital filtering) to ensure data validity. Data preprocessing feature extraction should be specific: Time-domain features: mean, variance (such as the moving average of speed data);

[0011] Frequency domain characteristics: FFT transform master frequency (e.g., spectrum analysis of current data);

[0012] Correlation characteristics: the relationship between braking force and operating speed;

[0013] If a data collection error occurs, a retry mechanism will be triggered (if the number of retries is less than 2, the data collection task will be restarted).

[0014] S3. Computing Power Analysis Steps: Monitor the idle computing power of edge devices. When the idle computing power is greater than 50%, select a high-precision AI model; otherwise, select a lightweight AI model. When computing power is insufficient, execute computing power optimization tasks, including disabling unnecessary signal acquisition or reducing the frequency of non-core tasks. Computing power optimization tasks also include dynamically adjusting task priorities and temporarily increasing the priority of core tasks to release computing resources. Computing power monitoring is performed periodically by low-priority resource monitoring tasks (calculating CPU utilization and memory usage). Computing power optimization tasks need to be refined: Dynamic priority adjustment: temporarily increase the priority of core tasks (e.g., AI inference from level 3 to level 2); Resource release: disable unnecessary register address signal acquisition (e.g., redundant sensors) and reduce the frequency of non-core tasks (e.g., extend the log recording task cycle to 500ms).

[0015] S4. AI Inference and RUL Prediction Steps: The selected AI model is used to perform trend analysis on the collected time series data to predict the remaining service life (RUL) of key elevator components. The high-precision AI model is based on the rotational inertia mathematical model, and the lightweight AI model is based on the simplified decision tree model. The RUL prediction results are used to dynamically adjust the frequency and intensity of no-load tests to prevent potential failures. The RUL prediction is based on two or more "score + time" data to determine the slope, coupled with the national standard time point to determine the next monitoring time point and stored in local Flash.

[0016] AI inference tasks need to be associated with the "Call High-Precision / Lightweight AI Model" node:

[0017] High-precision model: A mathematical model based on the rotational inertia of the rotating wheel, outputting precise values ​​for balance coefficient, braking force, etc.

[0018] Lightweight model: Based on a simplified decision tree or linear motion rotation inertia model, it outputs basic inference results.

[0019] RUL prediction is based on the slope calculated from two or more "score + time" data (using a linear regression algorithm), and coupled with the national standard time point to determine the next monitoring time;

[0020] The validity verification of the inference results needs to be supplemented: if the results of the lightweight model are unqualified, a degradation scheme (such as threshold-based rule judgment) should be implemented to ensure system fault tolerance;

[0021] S5. Monitoring Cycle Prediction Steps: Based on AI trend analysis results and RUL prediction, combined with the idle time period algorithm, analyze the elevator's historical operating data to generate an idle time period list, determine the time point for the next no-load monitoring, and ensure compliance with national standards. The idle time period algorithm is coupled with the elevator's peak and off-peak frequency, prioritizing low-load periods for monitoring to reduce interference with the normal operation of the elevator. The monitoring cycle prediction algorithm logic needs to be specified: continuously record elevator operating data (such as daily operating hours, number of starts and stops, and load status), summarize and generate historical records monthly, and use the idle time period algorithm to prioritize low-load periods (such as 2-4 am). The predicted time point must simultaneously meet the national standard cycle and RTOS algorithm output. When there is manual intervention, skip the prediction point and directly enter the high-priority task.

[0022] S6. No-load test execution steps: At the predicted time point, the no-load test is automatically executed to monitor the elevator's balance coefficient, braking force, and traction force. When a hardware fault is detected, the system switches to a redundant signal source and records the fault log. The fault handling includes a retry mechanism. When the number of retry attempts exceeds a threshold, a hardware restart or alarm operation is triggered. The monitoring results are uploaded through a low-cost collection method, including batch transmission by manual mobile devices or shared gateways to reduce network dependence. The test execution requires three major test processes: Braking force test: The car descends from the top floor to 1 / 3 of the shaft, automatically triggering a braking command and collecting average deceleration and torque data; Traction force test: The car descends from a random floor to the bottom floor and ascends at the calculated test speed (the traction ratio parameter needs to be manually entered), collecting deceleration data; Balance coefficient test: The car automatically positions itself to the balance position and executes a descending-stopping-ascending sequence at the inspection speed, collecting actual speed and power data; The fault handling adopts a graded retry mechanism: a hardware fault is retried twice and then restarted; data abnormalities are retried three times and then an alarm is triggered, and the system switches to a redundant signal source (e.g., changing the register address).

[0023] S7. Score Calculation and Optimization Steps: Calculate the monitoring score, adjust the monitoring cycle based on the slope change of the score and time. If the score is below the threshold, immediately stop the elevator and report an error. If the slope is gentle and the score is safe, extend the cycle. If the slope is steep and close to the threshold, shorten the cycle. Store the results in local Flash. The slope analysis is based on two or more monitoring data points, using a linear regression algorithm to calculate the trend change. Score calculation requires quantification rules: output 0-100 points based on experimental results. The slope analysis uses a linear regression algorithm. Specific strategies: score < 60 points: immediately stop the elevator and report an error; gentle slope and far from 60 points: extend the monitoring cycle; steep slope and close to 60 points: shorten the cycle to one week. Result storage needs to distinguish between "Flash storage" (immediate local storage) and "local temporary storage" (summary pool of all branch results, retained for 3-6 months) to prepare for subsequent aggregation.

[0024] S8. Data Upload and Big Data Optimization Steps: The collected data and monitoring results are securely uploaded to the remote big data platform via the TLS-AES-256-GCM encryption protocol. The platform performs big data analysis and optimizes the AI ​​model parameters, then updates them in reverse to the edge devices to achieve iterative optimization. The reverse update mechanism supports breakpoint resumption to ensure that optimization instructions are completely sent to the edge devices. The secure upload mechanism relies on the "Secure Upload and Remote Big Data Submodule": it supports breakpoint resumption and the national cryptographic SM2 algorithm to ensure data integrity. The reverse update process is specified as follows: After the platform optimizes the AI ​​model parameters, it sends instructions through the original link, which are then executed by the "Data Optimization and Reverse Update Submodule" (such as adjusting algorithm parameters during idle periods), and linked with manual intervention in the data optimization rule base.

[0025] S9. Manual Intervention Steps: Input test parameters through an embedded edge computing smart terminal. After the system performs a layered security review, execute a temporary no-load test. The test data is incorporated into the AI ​​training and optimization model. The security review includes system status verification, module readiness check, and rule matching to ensure that the intervention operation is performed under no-load conditions. The complete manual intervention process must be fully described: Command Input: Select the test type (e.g., braking force test) and input parameters (rated speed, traction ratio) through the touch screen; Security Review: Three-layer verification mechanism (system status verification: load rate <5%; module status verification: monitor module readiness; rule matching verification: parameters comply with national standards); Test Execution: Trigger the PFO interrupt wake-up task, release the execution semaphore, and display the data curve in real time; Data Closure: The test data is incorporated into the AI ​​training to optimize the prediction model.

[0026] Preferably, the method is applicable to the intelligent upgrade of existing elevators. By using an edge computing adapter library to shield hardware differences, it supports motherboard chips with different computing power specifications. The RUL prediction results are compared with the historical baseline of the remote big data platform to optimize the predictive maintenance threshold and improve the safe life of the elevator.

[0027] Preferably, the hardware reliability verification in the system initialization step S1 includes:

[0028] Verification of the validity of register address accesses focuses on verifying the validity of accesses to hardware register addresses such as speed, output torque, host current, and brake action control signals.

[0029] Verification of the validity of loading hardware kernel-mode drivers;

[0030] Verification of the validity of redundant sensor data acquisition;

[0031] By verifying the status of the motherboard chip memory and computing power, it was confirmed that the hardware resources meet the system's operating requirements.

[0032] 4. The elevator no-load monitoring method based on AI computing power analysis, RUL prediction, and big data optimization according to claim 1, characterized in that the fault handling in step S6 adopts a graded retry mechanism:

[0033] In case of hardware failure, perform a hardware restart operation after retrying twice;

[0034] If data is abnormal, an alarm message will be sent to the host computer after 3 retries.

[0035] Record the system status and context information at the time of the fault and retain the fault log;

[0036] The data optimization and reverse update submodule described in S8 embeds a lightweight AI time-series data processing algorithm to perform the following on the elevator time-series data:

[0037] Accurate removal of outliers;

[0038] Data standardization processing;

[0039] Trend feature extraction;

[0040] Provide high-quality input data for the AI ​​prediction and monitoring time module.

[0041] Preferably, the artificial intervention adaptation in S9 includes:

[0042] Touchscreen SPI communication verification and adaptation;

[0043] Physical key GPIO interrupt configuration adaptation;

[0044] Real-time reading of elevator safety signals serves as the underlying input for intervention and review;

[0045] During initialization, the communication link of the smart terminal is detected; if an abnormality is found, the intervention function is disabled.

[0046] The layered security review described in S10 employs a three-layer verification mechanism:

[0047] System status verification: No fault interruption, elevator unloaded (load rate <5%), no high-priority tasks executed in the edge data processing submodule;

[0048] Module status verification: Monitors whether the module is ready, no automatic experiments are being executed, and whether there are no inactive instructions in the data optimization and reverse update sub-modules;

[0049] Rule matching verification: The parameters are within the national standard range, and the matching FLASH rule base contains AI decision rules optimized from edge data;

[0050] S1 provides standardized interface encapsulation for the edge computing RTOS adaptation library layer:

[0051] AI algorithm interface encapsulation;

[0052] Secure transmission interface encapsulation;

[0053] Encapsulation of interrupt and manual intervention interfaces;

[0054] Standardized interface for edge data processing submodule.

[0055] Preferably, the low-cost collection described in S6 employs two methods:

[0056] Method A: Manual on-site collection at regular intervals. Maintenance personnel carry mobile collection equipment, insert it into the local interface of the edge module, and read the temporary data with one click and automatically encrypt and package it.

[0057] Method B: Regional shared gateway aggregation, with one low-cost shared gateway for every 10-20 elevators. Edge nodes upload temporary results to the shared gateway via short-range wireless timer.

[0058] Preferably, the entire method complies with the GB / T7588.2-2023 elevator safety standard and SIL2 safety level requirements, ensuring system reliability and compliance. The system interrupt management adopts NVIC priority grouping, binds interrupt lines to pins, and uses interrupt vector table mapping to ensure fast interrupt jump, providing real-time interrupt response for tasks such as edge data acquisition, secure uploading, and reverse update.

[0059] 8. The elevator no-load monitoring method based on AI computing power analysis, RUL prediction, and big data optimization according to claim 1, characterized in that, the monitoring cycle prediction algorithm in S5 continuously records various status data of elevator operation, including:

[0060] Runtime recording;

[0061] Number of start-stop cycles;

[0062] Load status (full load / no load ratio);

[0063] Operating frequency for each time period;

[0064] Monthly summaries are stored to form historical records, generating a list of idle time periods;

[0065] The slope analysis results described in S7 trigger different monitoring strategies:

[0066] If the current score is below 60, the system will immediately stop and report an error.

[0067] When the slope is gentle and far from 60 minutes, readjust the monitoring cycle;

[0068] If the slope is steep and close to 60 minutes, immediately shorten the monitoring cycle to one week.

[0069] Preferably, the edge data processing submodule cluster includes three cooperating submodules:

[0070] Edge data collection submodule: responsible for collecting and initially filtering elevator running sequence data;

[0071] Secure Upload and Remote Big Data Submodule: Enables secure data encapsulation and remote transmission;

[0072] Data Optimization and Reverse Update Submodule: Performs in-depth optimization processing on the collected data and executes reverse update commands.

[0073] Preferably, the complete manual intervention process described in S9 includes:

[0074] Command input stage: Select the test type and input parameters via the touch screen;

[0075] Interrupt Triggering and Instruction Parsing: PFO Interrupt Wake-up Instruction Parsing Task;

[0076] Security review: Invoke a three-tier security review mechanism;

[0077] Temporary test execution: Release the execution semaphore to wake up the experimental task;

[0078] Process recovery and data closure: After the experiment is completed, the automatic tasks are restored and the records are uploaded;

[0079] The system adopts a "five-layer, one-cluster" architecture design:

[0080] The underlying hardware layer provides the physical carrier for computing, storage, and communication.

[0081] BSP and CPU architecture support layer: Implement hardware driver abstraction and security verification;

[0082] RTOS kernel layer: ensures real-time performance through priority scheduling;

[0083] Edge computing RTOS adaptation library layer: provides standardized interface encapsulation;

[0084] Elevator Application Layer: Enables business implementation and process closure.

[0085] (III) Beneficial Effects

[0086] Compared with existing technologies, this invention provides a method for monitoring elevator no-load based on AI computing power analysis, RUL prediction, and big data optimization, which has the following beneficial effects:

[0087] 1. This elevator no-load monitoring method, based on AI computing power analysis, RUL prediction, and big data optimization, achieves adaptive resource scheduling by setting up a dynamic computing power allocation mechanism and an edge computing RTOS operating system. Specifically, it ensures real-time requirements by combining the idle computing power of edge devices (e.g., selecting a high-precision AI model when idle computing power is greater than 50%, otherwise selecting a lightweight model) with the task priority scheduling of the RTOS kernel layer (e.g., high-priority data acquisition tasks, medium-priority AI inference tasks). At the same time, it effectively adapts to the diverse motherboard chip computing power of existing elevators by optimizing tasks with computing power (e.g., shutting down unnecessary signal acquisition or reducing the frequency of non-core tasks), significantly reducing hardware upgrade costs and compliance expenditures. In addition, the edge computing RTOS adaptation library layer encapsulates standardized interfaces, improving the system's scalability and maintainability.

[0088] 2. This elevator no-load monitoring method, based on AI computing power analysis, RUL prediction, and big data optimization, achieves intelligent dynamic adjustment of the monitoring cycle by setting up an RUL prediction module based on AI time-series data trend analysis and an idle period algorithm. It generates a list of idle time periods using historical operating data (such as operating time, number of starts and stops, and load conditions), and predicts the next monitoring opportunity based on the slope analysis of two or more "score + time" data (using a linear regression algorithm) coupled with national standard time points. This not only improves the accuracy of remaining service life prediction, but also prioritizes the execution of no-load tests during low-load periods, reducing interference with the normal operation of the elevator, thereby optimizing resource utilization and enhancing fault prevention capabilities.

[0089] 3. This elevator no-load monitoring method, based on AI computing power analysis, RUL prediction, and big data optimization, achieves closed-loop system optimization and high reliability by setting up a secure data upload mechanism, reverse update function, and manual intervention process. Data is securely uploaded to a remote big data platform using the TLS-AES-256-GCM encryption protocol. After big data analysis, the platform reverse-optimizes the AI ​​model parameters and supports breakpoint resume to ensure complete instruction delivery. Simultaneously, manual intervention involves inputting parameters through an embedded edge computing smart terminal and employing layered security reviews (such as system status verification, module readiness checks, and rule matching) to ensure operational safety. Attached Figure Description

[0090] Figure 1 This is a diagram of the AI ​​embedded edge computing RTOS architecture of the present invention;

[0091] Figure 2 This is the operation process of the embedded edge computing smart terminal (handheld terminal) of the present invention;

[0092] Figure 3 This is a flowchart of the system initialization steps of the present invention;

[0093] Figure 4 This is a flowchart of the no-load monitoring process of the present invention;

[0094] Figure 5 For the present invention Figure 4 Flowchart of subsequent load monitoring in the middle. Detailed Implementation

[0095] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0096] Please see Figures 1-5 A method for monitoring elevator no-load based on AI computing power analysis, RUL prediction, and big data optimization includes the following steps:

[0097] S1. System Initialization Steps: Start the embedded edge computing RTOS operating system, perform hardware initialization, RTOS kernel initialization, and task scheduling initialization. Task scheduling includes high-priority data acquisition tasks, medium-priority AI inference tasks, and low-priority resource monitoring tasks to ensure real-time performance. Hardware initialization needs to be specific: initialize the CPU (e.g., ARM Cortex-M7), clock, memory, and elevator motherboard peripherals (encoder, communication ports), configure register addresses (e.g., speed register 0x01, current register 0x02), and fix the 100ms sampling period. Hardware reliability verification includes three layers of verification:

[0098] S2. Data Acquisition Steps: Configure and fix the register address for 100 milliseconds through the elevator motherboard chip to collect elevator running sequence data in real time, including speed, current, and torque parameters. Perform data preprocessing to extract time-domain and frequency-domain features. Data preprocessing includes data cleaning, noise filtering, and feature extraction. Feature extraction covers time-domain mean, variance, and frequency-domain FFT transform frequency. Data acquisition relies on the "edge data collection submodule": synchronously collect data from multiple physical quantity sensors (such as encoders and accelerometer chips) through the UART / EMAC interface, and integrate anti-interference filtering algorithms (such as digital filtering) to ensure data validity. Data preprocessing feature extraction should be specific: Time-domain features: mean, variance (such as the moving average of speed data);

[0099] Frequency domain characteristics: FFT transform master frequency (e.g., spectrum analysis of current data);

[0100] Correlation characteristics: the relationship between braking force and operating speed;

[0101] If a data collection error occurs, a retry mechanism will be triggered (if the number of retries is less than 2, the data collection task will be restarted).

[0102] S3. Computing Power Analysis Steps: Monitor the idle computing power of edge devices. When the idle computing power is greater than 50%, select a high-precision AI model; otherwise, select a lightweight AI model. When computing power is insufficient, execute computing power optimization tasks, including disabling unnecessary signal acquisition or reducing the frequency of non-core tasks. Computing power optimization tasks also include dynamically adjusting task priorities and temporarily increasing the priority of core tasks to release computing resources. Computing power monitoring is performed periodically by low-priority resource monitoring tasks (calculating CPU utilization and memory usage). Computing power optimization tasks need to be refined: Dynamic priority adjustment: temporarily increase the priority of core tasks (e.g., AI inference from level 3 to level 2); Resource release: disable unnecessary register address signal acquisition (e.g., redundant sensors) and reduce the frequency of non-core tasks (e.g., extend the log recording task cycle to 500ms).

[0103] S4. AI Inference and RUL Prediction Steps: The selected AI model is used to perform trend analysis on the collected time series data to predict the remaining service life (RUL) of key elevator components. The high-precision AI model is based on the rotational inertia mathematical model, and the lightweight AI model is based on the simplified decision tree model. The RUL prediction results are used to dynamically adjust the frequency and intensity of no-load tests to prevent potential failures. The RUL prediction is based on two or more "score + time" data to determine the slope, coupled with the national standard time point to determine the next monitoring time point and stored in local Flash.

[0104] AI inference tasks need to be associated with the "Call High-Precision / Lightweight AI Model" node:

[0105] High-precision model: A mathematical model based on the rotational inertia of the rotating wheel, outputting precise values ​​for balance coefficient, braking force, etc.

[0106] Lightweight model: Based on a simplified decision tree or linear motion rotation inertia model, it outputs basic inference results.

[0107] RUL prediction is based on the slope calculated from two or more "score + time" data (using a linear regression algorithm), and coupled with the national standard time point to determine the next monitoring time;

[0108] The validity verification of the inference results needs to be supplemented: if the results of the lightweight model are unqualified, a degradation scheme (such as threshold-based rule judgment) should be implemented to ensure system fault tolerance;

[0109] S5. Monitoring Cycle Prediction Steps: Based on AI trend analysis results and RUL prediction, combined with the idle time period algorithm, analyze the elevator's historical operating data to generate an idle time period list, determine the time point for the next no-load monitoring, and ensure compliance with national standards. The idle time period algorithm is coupled with the elevator's peak and off-peak frequency, prioritizing low-load periods for monitoring to reduce interference with the normal operation of the elevator. The monitoring cycle prediction algorithm logic needs to be specified: continuously record elevator operating data (such as daily operating hours, number of starts and stops, and load status), summarize and generate historical records monthly, and use the idle time period algorithm to prioritize low-load periods (such as 2-4 am). The predicted time point must simultaneously meet the national standard cycle and RTOS algorithm output. When there is manual intervention, skip the prediction point and directly enter the high-priority task.

[0110] S6. No-load test execution steps: At the predicted time point, the no-load test is automatically executed to monitor the elevator's balance coefficient, braking force, and traction force. When a hardware fault is detected, the system switches to a redundant signal source and records the fault log. The fault handling includes a retry mechanism. When the number of retry attempts exceeds a threshold, a hardware restart or alarm operation is triggered. The monitoring results are uploaded through a low-cost collection method, including batch transmission by manual mobile devices or shared gateways to reduce network dependence. The test execution requires three major test processes: Braking force test: The car descends from the top floor to 1 / 3 of the shaft, automatically triggering a braking command and collecting average deceleration and torque data; Traction force test: The car descends from a random floor to the bottom floor and ascends at the calculated test speed (the traction ratio parameter needs to be manually entered), collecting deceleration data; Balance coefficient test: The car automatically positions itself to the balance position and executes a descending-stopping-ascending sequence at the inspection speed, collecting actual speed and power data; The fault handling adopts a graded retry mechanism: a hardware fault is retried twice and then restarted; data abnormalities are retried three times and then an alarm is triggered, and the system switches to a redundant signal source (e.g., changing the register address).

[0111] S7. Score Calculation and Optimization Steps: Calculate the monitoring score, adjust the monitoring cycle based on the slope change of the score and time. If the score is below the threshold, immediately stop the elevator and report an error. If the slope is gentle and the score is safe, extend the cycle. If the slope is steep and close to the threshold, shorten the cycle. Store the results in local Flash. The slope analysis is based on two or more monitoring data points, using a linear regression algorithm to calculate the trend change. Score calculation requires quantification rules: output 0-100 points based on experimental results. The slope analysis uses a linear regression algorithm. Specific strategies: score < 60 points: immediately stop the elevator and report an error; gentle slope and far from 60 points: extend the monitoring cycle; steep slope and close to 60 points: shorten the cycle to one week. Result storage needs to distinguish between "Flash storage" (immediate local storage) and "local temporary storage" (summary pool of all branch results, retained for 3-6 months) to prepare for subsequent aggregation.

[0112] S8. Data Upload and Big Data Optimization Steps: The collected data and monitoring results are securely uploaded to the remote big data platform via the TLS-AES-256-GCM encryption protocol. The platform performs big data analysis and optimizes the AI ​​model parameters, then updates them in reverse to the edge devices to achieve iterative optimization. The reverse update mechanism supports breakpoint resumption to ensure that optimization instructions are completely sent to the edge devices. The secure upload mechanism relies on the "Secure Upload and Remote Big Data Submodule": it supports breakpoint resumption and the national cryptographic SM2 algorithm to ensure data integrity. The reverse update process is specified as follows: After the platform optimizes the AI ​​model parameters, it sends instructions through the original link, which are then executed by the "Data Optimization and Reverse Update Submodule" (such as adjusting algorithm parameters during idle periods), and linked with manual intervention in the data optimization rule base.

[0113] S9. Manual Intervention Steps: Input test parameters through an embedded edge computing smart terminal. After the system performs a layered security review, execute a temporary no-load test. The test data is incorporated into the AI ​​training and optimization model. The security review includes system status verification, module readiness check, and rule matching to ensure that the intervention operation is performed under no-load conditions. The complete manual intervention process must be fully described: Command Input: Select the test type (e.g., braking force test) and input parameters (rated speed, traction ratio) through the touch screen; Security Review: Three-layer verification mechanism (system status verification: load rate <5%; module status verification: monitor module readiness; rule matching verification: parameters comply with national standards); Test Execution: Trigger the PFO interrupt wake-up task, release the execution semaphore, and display the data curve in real time; Data Closure: The test data is incorporated into the AI ​​training to optimize the prediction model.

[0114] (I) System Initialization

[0115] 1. Hardware Initialization: After the system is powered on, the underlying hardware initialization is performed first. The initialization objects include the CPU (such as the ARM Cortex-M7 core), clock source, memory modules (such as Flash and RAM), and elevator motherboard peripherals (such as encoders, communication ports (UART, EMAC)). The initialization process requires configuring register addresses, such as the speed register (0x01), current register (0x02) and torque register (0x03), and fixing the sampling period timing of 100 milliseconds.

[0116] 2. Hardware Reliability Verification: Based on the "Hardware Reliability Verification" node, the validity of register accesses is verified in layers:

[0117] (1) Register address verification: Through the BSP layer driver, read the hardware register addresses such as speed, output torque, and host current, and check whether the return value is within the preset threshold (such as whether the speed value is within the range of 0-5m / s). If the read fails, trigger the retry mechanism.

[0118] (2) Kernel-mode driver loading verification: Verify the loading status of hardware kernel-mode drivers (such as encoder drivers) to ensure that the interrupt vector table is mapped correctly.

[0119] (3) Redundant sensor verification: Data acquisition tests are performed on redundant devices such as accelerometers, such as sending test data packets and checking the loopback response.

[0120] 3. Resource verification: Verify the memory and computing power status of the motherboard chipset to ensure that the resources meet the system requirements (e.g., memory remaining capacity > 80%).

[0121] (II) RTOS Kernel Initialization and Task Scheduling

[0122] 1. RTOS Kernel Initialization: Based on the RTOS kernel layer design, this initialization initializes the scheduler rules and priority mechanism, specifically including:

[0123] Priority grouping: NVIC priority grouping (4-bit preemption priority) is adopted, and interrupt lines are bound (such as EXTI8 corresponding to PFO interrupt) to ensure that the interrupt response time is <10μs.

[0124] Task initialization: Create a core task set, including high-priority data acquisition tasks (priority 1), medium-priority AI inference tasks (priority 3), and low-priority resource monitoring tasks (priority 6), and align them with the "Core Task Set Scheduling" node. After the task scheduler starts, it schedules tasks in a cyclical manner according to priority.

[0125] 2. Task scheduling initialization: The scheduler initializes the task list and priority list, starts the scheduling timer, and the task scheduling follows the "task priority?" judgment logic. High-priority tasks (such as data acquisition) can preempt low-priority tasks to ensure real-time performance.

[0126] Key points of implementation: After initialization, the system enters the "system self-test" judgment node. If the self-test is normal, the RTOS watchdog feeding mechanism is triggered; if there is an abnormality, the hardware fault handling process is entered.

[0127] (III) Data Collection Implementation

[0128] 1. Real-time data acquisition

[0129] Register address configuration: Through the BSP layer “hardware register data acquisition adapter” interface, a 100-millisecond sampling period is fixed to collect elevator running sequence data (speed, current, torque). The acquisition process integrates anti-interference filtering algorithms (such as digital filtering) to filter out abnormal fluctuation values.

[0130] Multi-source data integration: Using the "edge data collection submodule", data is synchronously collected from multiple physical quantity sensors (such as encoders and accelerometers) and transmitted to edge nodes via UART or EMAC interfaces. Data collection is triggered by high-priority tasks, and if an anomaly occurs, the "retry count judgment" process is entered.

[0131] 2. Data Preprocessing and Feature Extraction

[0132] Data cleaning: Call the "Data Preprocessing" node logic to filter noise (remove ±3σ outliers) and fill in missing values ​​in the raw data.

[0133] Feature extraction: Extract time-domain features (mean, variance) and frequency-domain features (FFT transform frequency). For example, calculate the moving average of velocity data and perform FFT analysis on current data. The feature vector is used as input for AI inference and is connected to the "AI inference task" node.

[0134] Key implementation points: The pre-processed data is pushed to the "edge data processing submodule cluster" to provide high-quality input for AI analysis.

[0135] (IV) Computing Power Analysis Steps

[0136] 1. Computing power monitoring and model selection

[0137] (1) Computing power monitoring: Real-time collection of CPU utilization and memory usage of edge devices (such as microcontrollers), calculation of idle computing power ratio, and the monitoring task is periodically executed by the "resource monitoring task" (low priority). (2) Model adaptive selection: When idle computing power > 50%, a high-precision AI model (such as the rotational inertia mathematical model) is called; otherwise, a lightweight model (such as a simplified decision tree) is called. The model switching logic is embedded in the cross-layer mechanism of the "AI engine".

[0138] 2. Computing power optimization task

[0139] Dynamic priority adjustment: When computing power is insufficient, temporarily increase the priority of core tasks (e.g., increase the priority of AI inference tasks from priority 3 to priority 2) and execute "computing power optimization tasks": turn off unnecessary signal acquisition (e.g., disable redundant sensors).

[0140] Reduce the frequency of non-core tasks (e.g., extend the resource monitoring task cycle from 100ms to 500ms).

[0141] Resource release: A "synchronization mechanism" (such as semaphores) is used to wake up dormant tasks and ensure efficient use of computing power.

[0142] Key implementation points: The optimization results are fed back to the "Data Optimization and Reverse Update Submodule" for iterative updates.

[0143] (vi) Extended Implementation of AI Inference and RUL Prediction Step (S4)

[0144] 1. AI Model Inference

[0145] High-precision model execution: When computing power is sufficient, call the "Call High-Precision AI Model" node ((Balance Coefficient / Braking Force / Torsion Reasoning)), input preprocessed data, and output accurate predicted values ​​of indicators such as balance coefficient and braking force. The model is based on the mathematical model of rotational inertia, such as the torque conversion in the traction force test.

[0146] Lightweight Model Degradation: When computing power is insufficient, the "Call Lightweight AI Model" is invoked, and simplified logic (such as linear regression) is used for trend analysis. The model results are verified through the "Determine if the Lightweight Inference Result is Valid" node. By determining whether the inference result of the lightweight AI model is valid, the results are ensured to have reference value. If "Yes": the process of "Result Qualified → Directly Output Lightweight Inference Result" is entered, and the inference result is used for subsequent processing. If "No": the process of "Result Unqualified → Execute Degradation Plan" is entered, and backup measures are taken to ensure system decision-making.

[0147] 2. Coupling of RUL prediction and monitoring cycle

[0148] Slope calculation: Based on two or more "score + time" data, the slope (S7) is calculated using a linear regression algorithm. The slope is coupled with the national standard time point to determine the next monitoring time point.

[0149] Data storage: The prediction results are stored in the local Flash memory, and the "Store next monitoring time and set reminder" node is triggered to determine and store the next monitoring time. At the same time, a reminder mechanism is set to ensure that the monitoring task is triggered on time. The next monitoring time is stored in the system log, and a self-check reminder is automatically triggered when the time is approaching, so that the system can prepare in advance and execute the next monitoring task on time.

[0150] Key implementation points: RUL prediction results are uploaded to the cloud via the "Secure Upload and Remote Big Data Submodule" to optimize thresholds.

[0151] (vii) Expanded implementation of the monitoring cycle prediction step (S5)

[0152] 1. Historical data recording and idle time period generation

[0153] Data recording: Continuously collect elevator operation data ("Start RTOS background task and collect and store historical data" node), start edge computing RTOS multi-physical quantity sensors (including balance coefficient, braking force, and traction force monitoring modules); continuously collect elevator operation history data (including daily running time, number of starts, load status, peak and off-peak operating frequency, etc.), summarize and store it as a historical record table by week / month, and synchronously store the next monitoring data into Flash; the monitoring results of the edge computing module are cached or uploaded through a secure network.

[0154] Idle Time Algorithm: Call the "Idle Time Algorithm" to analyze historical data and generate a list of idle time periods (such as the low-load period from 2 to 4 a.m.). The algorithm is coupled with the high and low frequency of elevator operation and prioritizes low-load periods for monitoring.

[0155] 2. Monitoring time prediction

[0156] RTOS time determinism: Using an RTOS timer (such as TIM5), the Predict_Next_Time() function is triggered to predict the next monitoring time. The time point must simultaneously meet the national standard cycle and the algorithm output.

[0157] Manual intervention skip mechanism: When there is manual intervention, the predicted time point is skipped and the task directly enters the high priority task.

[0158] Key implementation points: The prediction results are stored in Flash and retained for 3-6 months through the "local temporary storage at edge nodes" mechanism.

[0159] (viii) Execution of no-load test

[0160] 1. The test is executed automatically.

[0161] Test Triggering: At the predicted time point, the system automatically executes a no-load test, monitoring the balance coefficient, braking force, and traction force. The test procedure strictly follows the operating logic of the intelligent terminal.

[0162] Braking force test: When the car descends from the top floor to 1 / 3 of the way down the shaft, the braking command is automatically triggered, and the average deceleration and torque data are collected.

[0163] Traction test: The car descends from a random floor to the bottom floor, then ascends at the calculated test speed, and deceleration data is collected; Balance coefficient test: The car automatically positions itself to the balance position, and executes a descending-stopping-ascending sequence at the maintenance speed, collecting actual speed and power data.

[0164] Balance coefficient test: The car automatically positions itself to the balance position and executes a down-stop-up sequence at the maintenance speed, collecting actual speed and power data.

[0165] 2. Fault handling and redundancy switching

[0166] Tiered retry mechanism: Employs a "retry management module":

[0167] If a hardware failure occurs, the hardware will be restarted after two retries.

[0168] If data is abnormal, an alarm will be sent after 3 retries.

[0169] Redundancy switching: In case of failure, switch to an alternative signal source (such as changing the register address) to ensure data continuity.

[0170] Key implementation points: Test data is uploaded via a "low-cost collection" method (manual or shared gateway) to reduce network dependence. Specifically, low-cost collection is achieved through low-cost batch collection (replacing the need to install a network on each machine).

[0171] Method A: Manual on-site collection on a regular basis (suitable for scenarios where elevators are scattered). "Maintenance personnel regularly (e.g., monthly) carry a 'mobile collection device' (e.g., a USB flash drive / handheld terminal with encryption function), insert it into the local interface of the edge module, read the temporary data with one click, and automatically encrypt and package it."

[0172] Method B: Regional "Shared Gateway" aggregation (suitable for elevator clusters, such as residential communities / office buildings). "One "low-cost shared gateway" is set up for every 10-20 elevators (only one gateway is equipped with network hardware, and the cost is shared). Edge nodes upload the temporary results to the shared gateway at regular intervals (such as daily off-peak hours) via short-range wireless (such as LoRa / Bluetooth Low Energy).

[0173] (ix) Score Calculation and Optimization Implementation

[0174] 1. Score Calculation and Slope Analysis

[0175] Score quantification: The monitoring score (0-100 points) is calculated based on the test results. The score algorithm is embedded in a lightweight AI algorithm of the "data optimization and reverse update sub-module".

[0176] Slope analysis: Linear regression is used to calculate the slope of the score change over time. Slope judgment logic:

[0177] Score < 60 points: Immediately stop the elevator and report an error.

[0178] Gentle slope and safe score: Extend the monitoring cycle.

[0179] Steep slope and close to the threshold: shorten the cycle to one week.

[0180] 2. Data storage and iteration

[0181] Flash storage: Score and time data are stored in local Flash memory and linked to the "edge node local temporary storage" mechanism to support subsequent aggregation. The edge node local temporary storage mechanism specifically works as follows:

[0182] (1) Local non-networked temporary storage: Add a "local storage unit" (such as a low-cost Flash / SD card) to each elevator edge monitoring module (discrete node). "AI judgment and reasoning results (experimental data / fault warning / equipment status) will be automatically temporarily stored in the local storage unit (categorized by timestamp, with 3-6 months of storage reserved)".

[0183] (2) The relationship between "local temporary storage" and existing "Flash storage":

[0184] "Calculate monitoring score and store in Flash": This is the "real-time local storage" of the "high-precision AI model" (only the score and time of this high-precision monitoring are stored for local RTOS to call or short-term recording); "Local temporary storage": This is the "full branch result summary pool" (integrates high-precision results and lightweight effective results, and stores them in a unified category according to timestamps to prepare for subsequent "low-cost collection", with a longer storage period, such as 3-6 months).

[0185] Model optimization: The slope results are fed back to the cloud to update the AI ​​model parameters in reverse.

[0186] Key implementation points: The analysis results trigger "monitoring strategy adjustment" to achieve adaptive optimization.

[0187] (X) Data Upload and Big Data Optimization Implementation

[0188] 1. Secure upload mechanism

[0189] Encrypted transmission: Data is encrypted using the TLS-AES-256-GCM protocol and uploaded to the remote big data platform through the "secure upload" node. It supports breakpoint resumption to ensure data integrity. After "low-cost aggregation", the secure upload node uses the original "remote big data platform" link to securely upload to the remote big data platform. When there is no network, it uses "aggregated encrypted data packets (manually carried by the device / shared gateway) to access the 'secure network entry point' (such as VPN / encrypted 4G / enterprise intranet) and uploads them to the remote big data platform in a targeted manner".

[0190] Low-cost aggregation: using two aggregation methods:

[0191] Method A: Manually carry a mobile device to read local data.

[0192] Method B: Batch transmission via shared gateway (one gateway for every 10-20 elevators).

[0193] 2. Big Data Optimization and Reverse Update

[0194] Cloud analytics: The platform performs big data analysis to optimize AI model parameters and algorithms during idle periods.

[0195] Reverse Update: Optimization commands are sent to edge devices via the original link, where the "Data Optimization and Reverse Update Submodule" executes the update. This submodule performs deep optimization on the collected and transmitted data, and simultaneously updates the edge devices with optimization commands from the cloud or upper layers, enabling dynamic iterative optimization of the system. This supports the collaborative upgrade of AI prediction and human intervention, specifically through:

[0196] (1) Data optimization: Embed a lightweight AI time series data processing algorithm to accurately remove outliers, standardize data and extract trend features from elevator time series data, providing high-quality input data for AI prediction monitoring time modules (such as Predict_Next_Time()), improving the accuracy of AI prediction and ensuring the AI-driven needs of no-load monitoring.

[0197] (2) Reverse update: Design an efficient reverse update mechanism to synchronize the optimization strategies in the cloud (such as algorithm parameter adjustment during idle periods and AI model fine-tuning instructions) to the edge system in real time. After the update, the system parameter verification and activation process will be automatically triggered to ensure that the optimization instructions are implemented quickly and adapt to the system iteration requirements after manual intervention.

[0198] (3) Linkage optimization: In collaboration with the "Linkage optimization of human intervention and AI" module, human intervention records are incorporated into AI training data to optimize the security review rule base; when abnormal results of temporary experiments are triggered, the AI ​​model parameters are automatically fine-tuned and the prediction logic of Predict_Next_Time() is updated to continuously improve the system's intelligence level and adaptability, and realize the collaboration of "unmanned automatic operation + high-priority human intervention".

[0199] Key points for implementation: The upload process must comply with the "end-to-end security" requirements to ensure data traceability.

[0200] (xi) Implementation of artificial intervention

[0201] 1. Intervention command input and parsing

[0202] Command Input: Input test parameters (such as rated speed and traction ratio) through the embedded smart terminal (touch screen or physical keys). The terminal is connected to the elevator BT and automatically identifies the shaft parameters (described in "Parameter Settings"). For example: rated load capacity of the elevator (used for torque simulation of braking force test); custom maintenance speed (dedicated to balance coefficient test, which can be flexibly set by the user according to the needs, not a fixed value); traction ratio (a newly added key parameter used for "test speed calculation" and "torque conversion" in traction force test to ensure the accuracy of traction force judgment. It needs to be entered according to the actual configuration of the elevator, such as 1:1, 2:1, etc.).

[0203] Interrupt Trigger: The PFO interrupt wakes up the instruction parsing task and verifies the validity of the instruction.

[0204] 2. Layered security review

[0205] Three-layer verification mechanism (“security review”):

[0206] System status verification: No fault interruption, load rate < 5%, edge data processing submodule idle.

[0207] Module status verification: Monitors whether the module is ready or not, and automatically executes tests.

[0208] Rule matching verification: Parameters conform to national standard range and match Flash rule library.

[0209] Once the review is approved: release the execution semaphore to wake up the temporary test task.

[0210] 3. Temporary test execution and data closure

[0211] Test execution: Perform braking force, traction force or balance coefficient tests, and display the data on the terminal in real time.

[0212] Process recovery: After the experiment is completed, the automatic task is resumed, the data is uploaded to the cloud and incorporated into AI training.

[0213] Key Implementation Points: Manual intervention records are fed back into the security rule base through the "Manual Intervention and AI Linkage Optimization" module. This module periodically incorporates "intervention records" (review pass rate, experiment results) into AI training data via Secure_Upload() at the application layer to optimize the security review rule base (e.g., adjusting load detection thresholds to reduce false rejection rate). Abnormal results from temporary experiments (e.g., scores < 60 points) trigger Update_From_Cloud(), synchronizing to the cloud to trigger AI model fine-tuning and updating the prediction parameters of Predict_Next_Time(), thus achieving iterative optimization of the system.

[0214] In summary, this elevator no-load monitoring method based on AI computing power analysis, RUL prediction, and big data optimization achieves adaptive resource scheduling by setting up a dynamic computing power allocation mechanism and an edge computing RTOS operating system. Specifically, it ensures real-time requirements by combining the idle computing power of edge devices (e.g., selecting a high-precision AI model when idle computing power is greater than 50%, otherwise selecting a lightweight model) with task priority scheduling at the RTOS kernel layer (e.g., high-priority data acquisition tasks, medium-priority AI inference tasks). At the same time, it effectively adapts to the diverse motherboard chip computing power of existing elevators by optimizing tasks with computing power (e.g., disabling unnecessary signal acquisition or reducing the frequency of non-core tasks), significantly reducing hardware upgrade costs and compliance expenditures. In addition, the edge computing RTOS adaptation library layer encapsulates standardized interfaces, improving the system's scalability and maintainability.

[0215] Furthermore, by setting up a RUL prediction module based on AI time-series data trend analysis and an idle period algorithm, the intelligent monitoring cycle is dynamically adjusted. A list of idle time periods is generated using historical operating data (such as operating time, number of starts and stops, and load conditions). Based on the slope analysis of two or more "score + time" data (using a linear regression algorithm), the timing of the next monitoring is predicted by coupling with the national standard time point. This not only improves the accuracy of remaining service life prediction, but also prioritizes the execution of no-load tests during low-load periods, reducing interference with the normal operation of the elevator, thereby optimizing resource utilization and enhancing fault prevention capabilities.

[0216] Furthermore, by setting up a secure data upload mechanism, a reverse update function, and a manual intervention process, the system achieves closed-loop optimization and high reliability. Data is securely uploaded to a remote big data platform using the TLS-AES-256-GCM encryption protocol. After big data analysis, the platform reverse-optimizes the AI ​​model parameters and supports breakpoint resume to ensure complete instruction delivery. Meanwhile, manual intervention involves inputting parameters through an embedded edge computing smart terminal and employing layered security reviews (such as system status verification, module readiness checks, and rule matching) to ensure operational security.

[0217] It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0218] Although embodiments of the invention have been shown and described, it will be understood by those skilled in the art that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the invention, the scope of which is defined by the appended claims and their equivalents.

Claims

1. A method for monitoring elevator no-load based on AI computing power analysis, RUL prediction, and big data optimization, characterized in that, Includes the following steps: S1. System Initialization Steps: Start the embedded edge computing RTOS operating system, perform hardware initialization, RTOS kernel initialization, and task scheduling initialization. Task scheduling includes high-priority data acquisition tasks, medium-priority AI inference tasks, and low-priority resource monitoring tasks to ensure real-time performance. Hardware initialization needs to be specific: initialize the CPU (e.g., ARM Cortex-M7), clock, memory, and elevator motherboard peripherals (encoder, communication ports), configure register addresses (e.g., speed register 0x01, current register 0x02), and fix the 100ms sampling period. Hardware reliability verification includes three layers of verification: S2. Data Acquisition Steps: The elevator motherboard chip is configured and a 100-millisecond register address is permanently saved. Real-time elevator runtime sequence data, including speed, current, and torque parameters, is acquired. Data preprocessing is performed to extract time-domain and frequency-domain features. Preprocessing includes data cleaning, noise filtering, and feature extraction. Feature extraction covers time-domain mean, variance, and frequency-domain FFT transform frequency. Data acquisition relies on the "edge data aggregation submodule": synchronously acquiring data from multiple physical quantity sensors (such as encoders and accelerometers) via UART / EMAC interfaces, and integrating anti-interference filtering algorithms (such as digital filtering) to ensure data validity. Data preprocessing feature extraction should be specific: Time-domain features: mean, variance (such as the moving average of speed data). Frequency domain characteristics: FFT transform master frequency (e.g., spectrum analysis of current data); Correlation characteristics: the relationship between braking force and operating speed; If a data collection error occurs, a retry mechanism will be triggered (if the number of retries is less than 2, the data collection task will be restarted). S3. Computing Power Analysis Steps: Monitor the idle computing power of edge devices. When the idle computing power is greater than 50%, select a high-precision AI model; otherwise, select a lightweight AI model. When computing power is insufficient, execute computing power optimization tasks, including disabling unnecessary signal acquisition or reducing the frequency of non-core tasks. Computing power optimization tasks also include dynamically adjusting task priorities and temporarily increasing the priority of core tasks to release computing resources. Computing power monitoring is performed periodically by low-priority resource monitoring tasks (calculating CPU utilization and memory usage). Computing power optimization tasks need to be refined: Dynamic priority adjustment: temporarily increase the priority of core tasks (e.g., AI inference from level 3 to level 2); Resource release: disable unnecessary register address signal acquisition (e.g., redundant sensors) and reduce the frequency of non-core tasks (e.g., extend the log recording task cycle to 500ms). S4. AI Inference and RUL Prediction Steps: The selected AI model is used to perform trend analysis on the collected time series data to predict the remaining service life (RUL) of key elevator components. The high-precision AI model is based on the rotational inertia mathematical model, and the lightweight AI model is based on the simplified decision tree model. The RUL prediction results are used to dynamically adjust the frequency and intensity of no-load tests to prevent potential failures. The RUL prediction is based on two or more "score + time" data to determine the slope, coupled with the national standard time point to determine the next monitoring time point and stored in local Flash. AI inference tasks need to be associated with the "Call High-Precision / Lightweight AI Model" node: High-precision model: A mathematical model based on the rotational inertia of the rotating wheel, outputting precise values ​​for balance coefficient, braking force, etc. Lightweight model: Based on a simplified decision tree or linear motion rotation inertia model, it outputs basic inference results. RUL prediction is based on the slope calculated from two or more "score + time" data (using a linear regression algorithm), and coupled with the national standard time point to determine the next monitoring time; The validity verification of the inference results needs to be supplemented: if the results of the lightweight model are unqualified, a degradation scheme (such as threshold-based rule judgment) should be implemented to ensure system fault tolerance; S5. Monitoring Cycle Prediction Steps: Based on AI trend analysis results and RUL prediction, combined with the idle time period algorithm, analyze the elevator's historical operating data to generate an idle time period list, determine the time point for the next no-load monitoring, and ensure compliance with national standards. The idle time period algorithm is coupled with the elevator's peak and off-peak frequency, prioritizing low-load periods for monitoring to reduce interference with the normal operation of the elevator. The monitoring cycle prediction algorithm logic needs to be specified: continuously record elevator operating data (such as daily operating hours, number of starts and stops, and load status), summarize and generate historical records monthly, and use the idle time period algorithm to prioritize low-load periods (such as 2-4 am). The predicted time point must simultaneously meet the national standard cycle and RTOS algorithm output. When there is manual intervention, skip the prediction point and directly enter the high-priority task. S6. No-load test execution steps: At the predicted time point, the no-load test is automatically executed to monitor the elevator's balance coefficient, braking force, and traction force. When a hardware fault is detected, the system switches to a redundant signal source and records the fault log. The fault handling includes a retry mechanism. When the number of retry attempts exceeds a threshold, a hardware restart or alarm operation is triggered. The monitoring results are uploaded through a low-cost collection method, including batch transmission by manual mobile devices or shared gateways to reduce network dependence. The test execution requires three major test processes: Braking force test: The car descends from the top floor to 1 / 3 of the shaft, automatically triggering a braking command and collecting average deceleration and torque data; Traction force test: The car descends from a random floor to the bottom floor and ascends at the calculated test speed (the traction ratio parameter needs to be manually entered), collecting deceleration data; Balance coefficient test: The car automatically positions itself to the balance position and executes a descending-stopping-ascending sequence at the inspection speed, collecting actual speed and power data; The fault handling adopts a graded retry mechanism: a hardware fault is retried twice and then restarted; data abnormalities are retried three times and then an alarm is triggered, and the system switches to a redundant signal source (e.g., changing the register address). S7. Score Calculation and Optimization Steps: Calculate the monitoring score, adjust the monitoring cycle based on the slope change of the score and time, immediately stop the elevator and report an error if the score is below the threshold, extend the cycle if the slope is gentle and the score is safe, shorten the cycle if the slope is steep and close to the threshold, and store the results in local Flash. The slope analysis is based on two or more monitoring data points, and uses a linear regression algorithm to calculate the trend change. The score calculation needs to be quantified: output 0-100 points based on the test results, and use a linear regression algorithm for slope analysis. Specific strategies: score < 60 points: immediately stop the elevator and report an error; gentle slope and far from 60 points: extend the monitoring cycle; steep slope and close to 60 points: shorten the cycle to one week; the result storage needs to distinguish between "Flash storage" (immediate local storage) and "local temporary storage" (summary pool of all branch results, retained for 3-6 months) to prepare for subsequent collection. S8. Data Upload and Big Data Optimization Steps: The collected data and monitoring results are securely uploaded to the remote big data platform via the TLS-AES-256-GCM encryption protocol. The platform performs big data analysis and optimizes the AI ​​model parameters, then updates them in reverse to the edge devices to achieve iterative optimization. The reverse update mechanism supports breakpoint resumption to ensure that optimization instructions are completely sent to the edge devices. The secure upload mechanism relies on the "Secure Upload and Remote Big Data Submodule": it supports breakpoint resumption and the national cryptographic SM2 algorithm to ensure data integrity. The reverse update process is specified as follows: After the platform optimizes the AI ​​model parameters, it sends instructions through the original link, which are then executed by the "Data Optimization and Reverse Update Submodule" (such as adjusting algorithm parameters during idle periods), and linked with manual intervention in the data optimization rule base. S9. Manual Intervention Steps: Input test parameters through an embedded edge computing smart terminal. After the system performs a layered security review, execute a temporary no-load test. The test data is incorporated into the AI ​​training and optimization model. The security review includes system status verification, module readiness check, and rule matching to ensure that the intervention operation is performed under no-load conditions. The complete manual intervention process must be fully described: Command Input: Select the test type (e.g., braking force test) and input parameters (rated speed, traction ratio) through the touch screen; Security Review: Three-layer verification mechanism (system status verification: load rate <5%; module status verification: monitor module readiness; rule matching verification: parameters comply with national standards); Test Execution: Trigger the PFO interrupt wake-up task, release the execution semaphore, and display the data curve in real time; Data Closure: The test data is incorporated into the AI ​​training to optimize the prediction model.

2. The elevator no-load monitoring method based on AI computing power analysis, RUL prediction, and big data optimization according to claim 1, characterized in that, The method is applicable to the intelligent upgrade of existing elevators. It masks hardware differences through edge computing adapter libraries and supports motherboard chips with different computing power specifications. The RUL prediction results are compared with the historical baseline of the remote big data platform to optimize the predictive maintenance threshold and improve the safe life of the elevator.

3. The elevator no-load monitoring method based on AI computing power analysis, RUL prediction, and big data optimization according to claim 1, characterized in that, The hardware reliability verification in the system initialization step described in S1 includes: Verification of the validity of register address accesses focuses on verifying the validity of accesses to hardware register addresses such as speed, output torque, host current, and brake action control signals. Verification of the validity of loading hardware kernel-mode drivers; Verification of the validity of redundant sensor data acquisition; By verifying the status of the motherboard chip memory and computing power, it was confirmed that the hardware resources meet the system's operating requirements.

4. The elevator no-load monitoring method based on AI computing power analysis, RUL prediction, and big data optimization according to claim 1, characterized in that, The fault handling described in S6 employs a tiered retry mechanism: In case of hardware failure, perform a hardware restart operation after retrying twice; If data is abnormal, an alarm message will be sent to the host computer after 3 retries. Record the system status and context information at the time of the fault and retain the fault log; The data optimization and reverse update submodule described in S8 embeds a lightweight AI time-series data processing algorithm to perform the following on the elevator time-series data: Accurate removal of outliers; Data standardization processing; Trend feature extraction; Provide high-quality input data for the AI ​​prediction and monitoring time module.

5. The elevator no-load monitoring method based on AI computing power analysis, RUL prediction, and big data optimization according to claim 1, characterized in that, The artificial intervention adaptation described in S9 includes: Touchscreen SPI communication verification and adaptation; Physical key GPIO interrupt configuration adaptation; Real-time reading of elevator safety signals serves as the underlying input for intervention and review; During initialization, the communication link of the smart terminal is detected; if an abnormality is found, the intervention function is disabled. The layered security review described in S10 employs a three-layer verification mechanism: System status verification: No fault interruption, elevator unloaded (load rate <5%), no high-priority tasks executed in the edge data processing submodule; Module status verification: Monitors whether the module is ready, no automatic experiments are being executed, and whether there are no inactive instructions in the data optimization and reverse update sub-modules; Rule matching verification: The parameters are within the national standard range, and the matching FLASH rule base contains AI decision rules optimized from edge data; S1 provides standardized interface encapsulation for the edge computing RTOS adaptation library layer: AI algorithm interface encapsulation; Secure transmission interface encapsulation; Encapsulation of interrupt and manual intervention interfaces; Standardized interface for edge data processing submodule.

6. The elevator no-load monitoring method based on AI computing power analysis, RUL prediction, and big data optimization according to claim 1, characterized in that, S6 describes two methods for low-cost aggregation: Method A: Manual on-site collection at regular intervals. Maintenance personnel carry mobile collection equipment, insert it into the local interface of the edge module, and read the temporary data with one click and automatically encrypt and package it. Method B: Regional shared gateway aggregation, with one low-cost shared gateway for every 10-20 elevators. Edge nodes upload temporary results to the shared gateway via short-range wireless timer.

7. The elevator no-load monitoring method based on AI computing power analysis, RUL prediction, and big data optimization according to claim 1, characterized in that, The entire method complies with the GB / T7588.2-2023 elevator safety standard and SIL2 safety level requirements, ensuring system reliability and compliance. The system interrupt management adopts NVIC priority grouping, binds interrupt lines to pins, and uses interrupt vector table mapping to ensure fast interrupt jump, providing real-time interrupt response for tasks such as edge data acquisition, secure upload, and reverse update.

8. The elevator no-load monitoring method based on AI computing power analysis, RUL prediction, and big data optimization according to claim 1, characterized in that, The monitoring cycle prediction algorithm described in S5 continuously records various status data of the elevator operation, including: Runtime recording; Number of start-stop cycles; Load status (full load / no load ratio); Operating frequency for each time period; Monthly summaries are stored to form historical records, generating a list of idle time periods; The slope analysis results described in S7 trigger different monitoring strategies: If the current score is below 60, the system will immediately stop and report an error. When the slope is gentle and far from 60 minutes, readjust the monitoring cycle; If the slope is steep and close to 60 minutes, immediately shorten the monitoring cycle to one week.

9. The elevator no-load monitoring method based on AI computing power analysis, RUL prediction, and big data optimization according to claim 5, characterized in that, The edge data processing submodule cluster comprises three collaborative submodules: Edge data collection submodule: responsible for collecting and initially filtering elevator running sequence data; Secure Upload and Remote Big Data Submodule: Enables secure data encapsulation and remote transmission; Data Optimization and Reverse Update Submodule: Performs in-depth optimization processing on the collected data and executes reverse update commands.

10. The elevator no-load monitoring method based on AI computing power analysis, RUL prediction, and big data optimization according to claim 1, characterized in that, The complete manual intervention process described in S9 includes: Command input stage: Select the test type and input parameters via the touch screen; Interrupt Triggering and Instruction Parsing: PFO Interrupt Wake-up Instruction Parsing Task; Security review: Invoke a three-tier security review mechanism; Temporary test execution: Release the execution semaphore to wake up the experimental task; Process recovery and data closure: After the experiment is completed, the automatic tasks are restored and the records are uploaded; The system adopts a "five-layer, one-cluster" architecture design: The underlying hardware layer provides the physical carrier for computing, storage, and communication. BSP and CPU architecture support layer: Implement hardware driver abstraction and security verification; RTOS kernel layer: ensures real-time performance through priority scheduling; Edge computing RTOS adaptation library layer: provides standardized interface encapsulation; Elevator Application Layer: Enables business implementation and process closure.

Images