Building full-link elevator control method and intelligent system
By parsing elevator contract numbers to generate unique station identifiers, device grouping and permission configuration are performed. A lightweight AI model is deployed on the edge gateway for real-time data collection and preprocessing. Combined with cloud federated servers and blockchain evidence storage, the problems of low deployment efficiency, inaccurate data monitoring, difficulty in protecting privacy, unreliability of offline operations, and untrustworthy traceability in smart building elevator control systems are solved, achieving efficient and reliable end-to-end elevator control.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- HITACHI BUILDING TECH GUANGZHOU CO LTD
- Filing Date
- 2026-02-28
- Publication Date
- 2026-04-10
AI Technical Summary
The intelligent building elevator control system has significant pain points in terms of low site creation efficiency, inaccurate data perception, difficulty in protecting privacy, unreliability of offline operation, untrustworthy traceability, and incompatibility with various scenarios.
By receiving and parsing elevator contract numbers, generating unique station identifiers, grouping devices and configuring initial permissions, deploying lightweight AI models on edge gateways for real-time data collection and preprocessing, utilizing edge computing power for anomaly detection, and combining cloud federated servers for model aggregation and blockchain notarization, intelligent early warning and reliable traceability are achieved across the entire chain.
It improves the deployment efficiency and data monitoring accuracy of the elevator control system, ensures privacy protection, enhances offline fault tolerance, realizes reliable traceability and scenario adaptation across the entire chain, and meets the requirements of Level 3 Information Security Protection.
Smart Images

Figure CN121823344A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of elevator control technology, and in particular to a building-wide elevator control method and intelligent system. Background Technology
[0002] Current smart building elevator control systems have significant pain points in terms of site creation, equipment operation and maintenance, data collaboration, and security traceability: Site creation is inefficient, relying on manual Excel import, and each site takes a long time to create. Furthermore, the templates are rigid and cannot adapt to different scenarios, and there is a lack of validation for implicit business rules (such as contract area consistency).
[0003] Insufficient data perception and early warning capabilities, relying on minute-level data collection, cannot capture millisecond-level instantaneous fault symptoms; the early warning mechanism that depends on fixed thresholds cannot adapt to equipment aging and environmental changes, resulting in a high rate of false alarms and missed alarms.
[0004] Data silos and privacy conflicts exist. To optimize the model, it is necessary to aggregate data from multiple buildings, but directly sharing sensitive information such as elevator operation frequency and access control records poses privacy and compliance risks.
[0005] Edge computing power is underutilized and offline capabilities are lacking. Edge gateways are only used as data channels, and computing power is not fully utilized. On-site mobile operations lack offline caching mechanisms, and network interruptions can easily lead to data loss.
[0006] The lack of end-to-end traceability and the scattered and easily tampered operation logs make it impossible to meet the mandatory requirement of "operation traceability" for Level 3 Information Security Protection.
[0007] Therefore, there is an urgent need in this field for an end-to-end integrated solution that can achieve efficient deployment, intelligent early warning, privacy protection, offline fault tolerance, and security traceability. Summary of the Invention
[0008] To address or partially address the problems existing in related technologies, this application provides a building-wide elevator control method and intelligent system, aiming to solve multi-dimensional technical problems such as low deployment efficiency, inaccurate monitoring, difficulty in protecting privacy, unreliable offline operation, untrustworthy traceability, and incompatibility with various scenarios in smart building elevator control systems.
[0009] The first aspect of this application provides a building-wide elevator control method, including: Receive and parse the elevator contract number, associate customer and building information based on the contract number, generate a unique site identifier, and perform device grouping and initial permission configuration; perform offline synchronization configuration, cache the site configuration data on the mobile terminal, and perform atomic synchronization operation after the network is restored; Real-time data acquisition at the edge: The raw data stream of elevator operation is periodically collected through the edge gateway, and the raw data stream is filtered and preprocessed in real time to extract key feature data. Deploy a lightweight AI model on the edge gateway to perform real-time inference based on key feature data, identify device anomalies, and trigger multiple real-time alerts; when the device operates normally for a continuous set period of time, use the data of that period to fine-tune the local model parameters to achieve local model adaptation. Each edge gateway periodically calculates the parameter difference between the local model and the global model, adds noise that meets differential privacy requirements to the parameter difference, and then uploads it to the cloud federated server. The cloud federated server performs weighted aggregation on the encrypted parameter difference based on the number of devices in each building, generates a new version of the global model, and securely distributes it to each edge gateway for updates. At key business nodes such as successful site creation, equipment malfunction, and completion of maintenance, structured logs are generated, the hash value of the logs is calculated, and the hash value is associated with the device identifier and written to the blockchain for evidence storage; query and verification interfaces based on evidence storage identifiers or device identifiers are provided to achieve reliable traceability of the entire operation chain.
[0010] Optionally, generate a unique site identifier, including: The elevator contract number is parsed into a fixed format, which is: HT + 4-digit year + 2-digit month + 2-digit day + 2-digit area code + 2-digit serial number; The API automatically associates customer ID, building type, number of elevators, and equipment model information to achieve the initial mapping between business credentials and digital information, and associates and populates customer information and building type. The Snowflake algorithm is used to generate unique site IDs, with the generation rule being: area abbreviation + building number + 3-digit serial number; At the same time, device groups and administrator accounts are created, and the initial permissions of the administrator accounts are bound to the corresponding sites.
[0011] Optionally, generating a unique site identifier also includes: Based on historical configuration data cached in Redis, the similarity is calculated using an Item-Based collaborative filtering algorithm to recommend personalized service types, device grouping strategies, and permission granularities for newly created sites. Integrate the Drools rule engine to perform dynamic business rule verification and pre-set core business rules for the upper limit of the number of sites bound to the employee ID and the consistency of the contract number region.
[0012] Optionally, the raw data stream is subjected to real-time filtering preprocessing, and key feature data is extracted, including: The edge gateway subscribes to and collects raw data streams of device current and card reader signals at a minimum period of 100ms via the extended MQTT protocol. Sliding window weighted filtering is used to suppress noise; Real-time calculation of three key features: 5-second current variance, door switch response time, and number of consecutive card reading failures; A hybrid mechanism of abnormal triggering and periodic reporting is adopted to upload compressed feature data, thereby reducing bandwidth usage.
[0013] Optionally, lightweight AI models can be deployed at the edge gateway, including: The edge gateway loads a time-series fusion Transformer model with INT8 integer quantization algorithm to adapt to the limited computing power on the edge side, realize local edge inference, and accurately identify motor overload, gate jamming, and intermittent card reader interruption. Upon detecting an anomaly, the system pushes the data to the operations and maintenance platform in real time via WebSocket, and also sends alarm information and related data graphs via SMS / APP. If the equipment operates normally for 7 consecutive days, the model parameters will be automatically fine-tuned using the data from that period to adapt the model to the aging and performance drift of the equipment.
[0014] Optionally, the cloud-based federated server performs a weighted aggregation of the encrypted parameter differences based on the number of devices in each building, including: The cloud-based federated server uses the FedAvg algorithm to perform weighted aggregation based on the number of devices in each building, generating a new global model. The formula for calculating the weighting coefficients is as follows: (2) In the formula, Let be the weighting coefficient for the i-th building. Let be the number of elevators in building i. The total number of all building facilities participating in the federation; The encrypted new global model is distributed to each edge gateway through a dedicated channel. After the gateway decrypts the data, it updates its local model, thus improving the performance of the model by ensuring that the data stays within the building.
[0015] Optionally, to achieve trusted traceability of the entire operation chain, including: At key points such as successful site creation, device malfunction, and completion of operation and maintenance, structured logs are generated to ensure that the logs are closely related to business logic. The log format is: evidence ID, device MAC address, operation type, operation time, operation content, and operator employee number. The structured logs are hashed using SHA-256, with a hash value length of 64 bits, to generate an immutable log digest, providing a basis for subsequent on-chain evidence storage and ensuring the integrity of the log content. Deploy a Hyperledger Fabric consortium blockchain node cluster locally, deploying three types of consortium blockchain nodes: park operation and maintenance center nodes, elevator manufacturer nodes, and third-party audit institution nodes. Adopt the Raft consensus mechanism to form a trusted evidence storage network, avoid the risk of tampering by a single node, replace general blockchain evidence storage, and realize scenario-based customization. After strongly associating the hash digest with the device's unique identifier, it is written into the consortium blockchain, supporting automatic evidence storage triggered by AI anomaly detection and site-created context-associated evidence storage, thus realizing proactive linkage between evidence storage and business flow. It provides an interface to query the evidence storage ID or device MAC address. By comparing the hash value on the consortium blockchain with the hash value recalculated from the business data, it verifies the authenticity of the record, realizes cross-entity penetration audit, meets the requirements of Level 3 Information Security Protection, and clarifies the responsibilities of the entire chain.
[0016] Optional, building-wide elevator control methods also include: Three types of emergency response plans for the edge: Edge gateway fault redundancy is implemented, with a primary and backup gateway hot standby mechanism configured. The primary gateway sends a heartbeat signal to the backup gateway every 500ms. If the backup gateway fails to receive the heartbeat signal three times consecutively, it determines that the primary gateway has failed and automatically takes over the data collection and inference tasks of the primary gateway. After the primary gateway recovers, the backup gateway returns the tasks to the primary gateway through incremental synchronization to avoid data loss. For sudden power outages, the edge gateway has a built-in emergency battery. After a power outage, it triggers a mechanism to instantly write data to Flash, writing the original data and feature data from the 10 seconds before the power outage to the local Flash memory. After power is restored, the system automatically reads the data from the Flash memory and retransmits it to the cloud, ensuring no data loss at the millisecond level. Multi-building scenario adaptation: Providing scenario-based configuration templates to meet the differentiated needs of different building types. For residential buildings, a low data collection frequency and a low model update frequency are adopted, and a high privacy protection strategy is implemented. Commercial complexes employ high data collection frequency and high model update frequency, while implementing privacy protection strategies. For office buildings, a medium data collection frequency and a medium model update frequency are adopted, and a medium privacy protection strategy is implemented.
[0017] The second aspect of this application provides a building end-to-end intelligent elevator control system, comprising: The business-driven and site management layer is used to receive and parse elevator contract numbers to achieve automated site creation, scenario configuration recommendation, business rule verification, and offline data synchronization. The edge awareness and data preprocessing layer, deployed on the edge gateway, is used for millisecond-level data acquisition, streaming data preprocessing, key feature extraction, and data transmission optimization. The intelligent detection and model self-evolution layer is deployed on the edge gateway to load lightweight AI models for real-time anomaly detection, trigger immediate warnings, and achieve local adaptive updates of the model. The federated collaborative optimization layer, including the cloud federated server, is used to aggregate the model parameter differences of each edge gateway under the premise of privacy protection, and generate and distribute a new version of the global model. The blockchain security storage layer is used to generate structured logs at key business nodes, calculate hash values and write them to the blockchain, providing trusted traceability and verification functions; The edge emergency protection layer is used to realize the primary and backup hot standby of the edge gateway, data protection in case of sudden power failure, and differentiated configuration adaptation for multi-building scenarios.
[0018] Optional, business-driven and site management layers include: The contract number parsing and information association module is used to receive and parse elevator contract numbers into a fixed format, and automatically associate customer and building information through API to realize the initial mapping between business vouchers and digital information. The automatic site creation module generates unique site IDs using the Snowflake algorithm and simultaneously completes device grouping and administrator account creation. The scenario-based configuration recommendation module recommends personalized service types, device grouping strategies, and permission granularity for newly created sites based on historical configuration data and through an item-based collaborative filtering algorithm. The dynamic business rule verification module integrates the Drools rule engine and presets core verification rules. The offline synchronization and caching module temporarily stores site configurations and operation logs in the mobile device's database when the network is interrupted; after the network is restored, atomic synchronization is achieved through the interface. The edge sensing and data preprocessing layer includes: The edge gateway hardware unit, as the core hardware on the edge side, supports primary and backup hot standby and is equipped with extended MQTT protocol parsing and lightweight computing capabilities; The millisecond-level streaming acquisition module, based on the extended MQTT protocol, subscribes to the elevator's raw data at a minimum period of 100ms. The streaming data preprocessing module uses a sliding window weighted filtering algorithm to suppress noise in the raw data. The key feature extraction module calculates the 5-second current variance, door switch response time, and number of consecutive card reading failures in real time, providing input features for AI anomaly detection. The data compression and transmission optimization module adopts a hybrid mechanism of abnormal triggering and periodic reporting, and uploads feature data through GZIP compression to avoid uploading the full data. The intelligent detection and model self-evolution layer includes: The lightweight AI model deployment module loads the time-series fusion Transformer model on the edge gateway, adapting to the limited computing power on the edge side and enabling local edge inference. The real-time edge inference module, by inputting feature sequences, accurately identifies anomalies such as motor overload, gate jamming, and intermittent card reader disconnection. The multi-channel real-time early warning module detects an anomaly and pushes it to the operation and maintenance platform in real time via WebSocket, while also linking SMS / APP to push alarm information and data screenshots; The model local adaptive module fine-tunes the model parameters using the feature data of that period if there are no abnormal warnings for the equipment within a continuous time period, in order to adapt to the performance drift caused by equipment aging. The federated collaborative optimization layer includes: The edge-side model parameter calculation module automatically calculates the weight difference between the local model and the current global model for each edge gateway, providing basic data for federated aggregation. The differential privacy protection module adds Laplace noise to the weight difference to meet differential privacy requirements. The cloud-based federated aggregation server deploys the FedAvg algorithm, calculates weighting coefficients based on the number of elevators in each building, and aggregates the weight differences uploaded by each edge gateway to generate a new version of the global model, thereby improving the performance of the global model. The global model encryption and distribution module uses AES-256 to encrypt the new version of the global model and distributes it to each edge gateway through a dedicated encrypted channel. The edge model update module decrypts and overwrites the local old version of the global model, thereby improving the overall model performance of the entire system. The blockchain secure evidence storage layer includes: The structured log generation module automatically generates structured logs at key nodes, ensuring that the logs are closely related to business logic; The SHA-256 hashing module performs SHA-256 hashing on structured logs to generate an immutable log digest. The HyperledgerFabric consortium blockchain node cluster deploys nodes from the park's operation and maintenance center, elevator manufacturers, and third-party auditing agencies. It adopts the Raft consensus mechanism to form a trusted evidence storage network, replacing general-purpose blockchain evidence storage and enabling scenario-based customization. The blockchain evidence storage writing module writes the hash digest and the device's unique identifier into the consortium blockchain. It also supports automatic evidence storage triggered by anomaly detection and evidence storage related to site creation context, enabling proactive linkage between evidence storage and business flow, and embedding full-link business logic. The trusted traceability and verification module provides a query interface to verify the authenticity of records by comparing the hash value on the chain with the hash value recalculated from the business data, thereby meeting the requirements of Level 3 Information Security Protection and clarifying the responsibilities across the entire chain. The edge emergency support layer includes: The primary / backup gateway hot standby module configures a backup gateway for the primary edge gateway. The primary gateway sends a heartbeat signal to the backup gateway every 500ms. If the backup gateway fails to receive heartbeats for three consecutive times, it takes over the data acquisition and inference tasks within 1.5 seconds. After the primary gateway recovers, the backup gateway returns the tasks through incremental synchronization, thus solving the single point of failure problem of the edge gateway. The sudden power outage data protection module has an emergency battery built into the edge gateway. After a power outage, it triggers a mechanism to instantly write data to Flash, writing the original data and feature data from the 10 seconds before the power outage to the local Flash. After power is restored, it automatically reads the Flash data and retransmits it to the cloud, thus addressing the risk of data loss due to sudden power outages. The multi-building scenario adaptation module has three preset scenario-based configuration templates for residential buildings, commercial complexes, and office buildings to adapt to different building needs.
[0019] The technical solution provided in this application may include the following beneficial effects: Using the elevator contract number as the core business credential, the system deeply integrates site creation, data perception, intelligent analysis, model evolution, and security auditing to construct an integrated closed loop from business-driven to trusted traceability, forming an intelligent system with self-evolution and self-adaptation capabilities. It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and do not limit this application. Attached Figure Description
[0020] The above and other objects, features and advantages of this application will become more apparent from the more detailed description of exemplary embodiments thereof in conjunction with the accompanying drawings, wherein the same reference numerals generally represent the same components in the exemplary embodiments thereof.
[0021] Figure 1 This is a schematic flowchart illustrating the building end-to-end elevator control method in the embodiments of this application; Figure 2 This is a schematic diagram of the structure of a building-wide intelligent elevator control system as shown in the embodiments of this application. Detailed Implementation
[0022] Embodiments of this application will now be described in more detail with reference to the accompanying drawings. While embodiments of this application are shown in the drawings, it should be understood that this application may be implemented in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided to make this application more thorough and complete, and to fully convey the scope of this application to those skilled in the art.
[0023] The technical solutions of the embodiments of this application are described in detail below with reference to the accompanying drawings.
[0024] Figure 1 This is a schematic flowchart illustrating the building end-to-end elevator control method in the embodiments of this application.
[0025] In some implementations, see Figure 1 A building-wide elevator control method, comprising: S101. Receive and parse the elevator contract number, associate customer and building information based on the contract number, generate a unique site identifier, and perform device grouping and initial permission configuration; perform offline synchronization configuration, cache the site configuration data on the mobile terminal, and perform atomic synchronization operation after the network is restored.
[0026] Specifically, contract number parsing and information association: The elevator contract number is parsed into a fixed format: HT + 4-digit year + 2-digit month + 2-digit day + 2-digit area code + 2-digit serial number, such as HT20240520A01, where A0 represents the area code and 01 represents the serial number. By calling the backend RESTful API, customer ID, customer name, building type, number of elevators, and equipment model are automatically associated, and customer information and building type are populated.
[0027] Unique site IDs are generated using the Snowflake algorithm, following the rule: region abbreviation + building number + 3-digit serial number, such as ZG-A-001, where ZG is the abbreviation of a region, A is the building number, and 001 is the serial number. Device groups and administrator accounts are automatically created simultaneously. Device groups default to 10 devices per group, and administrator accounts are initially bound to the corresponding sites.
[0028] Scenario-based configuration recommendations are based on historical configuration data cached in Redis. The similarity is calculated using an item-based collaborative filtering algorithm with a similarity threshold of ≥0.85. Personalized service types, device grouping strategies, and permission granularities are recommended for newly created sites. Service types include elevator control + energy consumption monitoring and elevator control + security linkage. Device grouping strategies are 5 devices / group or 10 devices / group, and permission granularities are administrator / maintenance personnel / viewer.
[0029] Dynamic business rule validation, integrated with the Drools rule engine, with two preset core business rules: The maximum number of sites a single employee ID can be bound to is 5. Contract number area consistency: The contract number area code must match the actual building area. For example, area code A0 corresponds to building A in a certain place.
[0030] If the verification fails, specific repair suggestions will be returned. For example, if employee ID Z001 is bound to 5 sites, you need to unbind 1 site and try again.
[0031] Site generation is synchronized offline. After verification, site configuration is automatically generated. When the network is interrupted, all data is temporarily stored in the SQLite database on the mobile device. The database table structure includes site ID, contract number, configuration parameters, and synchronization status. After the network is restored, atomic synchronization is performed through the dedicated interface POST / api / v1 / sync / offlineData. If synchronization fails, it will automatically retry 3 times with an interval of 10 seconds.
[0032] S102. Real-time data acquisition at the edge: The raw data stream of elevator operation is periodically acquired through the edge gateway, and the raw data stream is filtered and preprocessed in real time to extract key feature data.
[0033] Specifically, for millisecond-level streaming acquisition, the edge gateway subscribes to and collects raw data streams such as device current, gating status, and card reader signals at a minimum period of 100ms using the extended MQTT protocol. The extended MQTT protocol adds two extended fields: acquisition period and device status flag.
[0034] For streaming preprocessing and feature extraction, a sliding window weighted filter is used to suppress noise. The window size of the sliding window weighted filter is 5 seconds. The weighting coefficients are as follows: the weight of data in the first 1-2 seconds is 0.3, the weight of data in the 3rd-4th seconds is 0.5, and the weight of data in the 5th second is 0.7.
[0035] Real-time calculation of three key features: 5-second current variance, door switch response time, and number of consecutive card reading failures.
[0036] Data transmission is optimized by adopting a hybrid mechanism of abnormal triggering and periodic reporting. The compressed feature data is only uploaded when the feature value exceeds the preset normal range or reaches the 1-minute cycle, which reduces bandwidth usage by more than 60%. Among them, the preset normal range, such as current variance of 5A², door switch response time of 10s, and three consecutive card reading failures, is compressed using GZIP compression with a compression rate of ≥60%.
[0037] S103. Deploy a lightweight AI model on the edge gateway, perform real-time inference based on key feature data, identify device anomalies, and trigger multiple real-time alerts; when the device operates normally for a continuous set time period, use the data of that period to fine-tune the local model parameters to achieve local model adaptation.
[0038] Specifically, the edge gateway loads a time-series fusion Transformer model using the INT8 integer quantization algorithm. The Transformer model is less than 15MB in size and its structure includes: a 3-layer encoder, 4 attention heads, and 8-dimensional input features. It takes a feature sequence of nearly 30 seconds as input, with a sampling frequency of 1 time / second and a total of 30 feature points. It completes inference within 20ms and accurately identifies anomalies such as motor overload, gate jamming, and intermittent card reader interruptions.
[0039] Multiple real-time alerts are provided. Upon detecting an anomaly, the alerts are pushed to the operations and maintenance platform in real time via WebSocket, and are also sent via SMS / APP with alarm information and relevant data screenshots. The alarm information includes the anomaly type, occurrence time, and device number.
[0040] The model is locally adaptive. If the equipment operates normally for 7 consecutive days without any abnormal warning records, the model parameters are automatically fine-tuned using the data from that period. The learning rate is 1e-4, the number of iterations is 50 rounds, and the batch size is 16, so that the model can adapt to the aging of the equipment and performance drift, such as the rise in the current baseline caused by motor aging.
[0041] S104. Each edge gateway periodically calculates the parameter difference between the local model and the global model, adds noise that meets differential privacy requirements to the parameter difference, and then uploads it to the cloud federated server. The cloud federated server performs weighted aggregation on the encrypted parameter difference based on the number of devices in each building, generates a new version of the global model, and securely distributes it to each edge gateway for updates.
[0042] Specifically, regarding parameter differentiation and privacy handling, at 00:00 on the 1st of each month, each edge gateway calculates the weight difference ΔW between the local model and the global model, where ΔW = local model weight - global model weight. Laplace noise is then added, with the noise formula as follows: (1) In the formula, λ = 1 / ε, ε = 0.5; The weight difference is made to meet the differential privacy requirements, and then uploaded with TLS 1.3 encryption.
[0043] Weighted aggregation and global update: The cloud-based federated server uses the FedAvg algorithm to aggregate the weight differences ΔW based on the number of devices in each building, generating a new global model. The formula for calculating the weighting coefficients is as follows: (2) In the formula, Let be the weighting coefficient for the i-th building. Let be the number of elevators in building i. This represents the total number of all building facilities participating in the federation.
[0044] The model is securely distributed by encrypting the new global model using AES-256 and distributing it to each edge gateway through a dedicated channel. After decryption, the gateway updates its local model, thus improving the performance of the model by ensuring that the data stays within the building.
[0045] S105. At key business nodes such as successful site creation, equipment malfunction, and completion of operation and maintenance, generate structured logs, calculate the hash value of the logs, associate the hash value with the device identifier, and write it to the blockchain for evidence storage; provide query and verification interfaces based on evidence storage identifiers or device identifiers to achieve reliable traceability of the entire operation chain.
[0046] Specifically, the evidence stored is not isolated operation logs, but structured business events that span the entire lifecycle of the elevator control system, with contract number, site ID, device MAC address, and operator employee number as key indexes. These site creation, device anomaly, and maintenance handling events naturally form a chain of responsibility that is interconnected in business logic, making each instance of evidence storage on the blockchain a trusted node in that business chain, rather than an information silo.
[0047] Cross-entity, penetrating auditing, based on the binding relationship between contract numbers and sites / devices, allows auditors to perform penetrating queries through any dimension, such as evidence ID, device MAC, contract number, or employee ID, quickly reconstructing the complete trajectory from equipment installation and anomaly occurrence to maintenance and handling. This solves the problems of easy data tampering, poor correlation, and difficulty in cross-entity traceability in traditional distributed log systems, and meets the mandatory requirements of Level 3 Information Security Protection for operational traceability.
[0048] Unlike passive recording, blockchain-based evidence storage actively interacts with other stages of the system. For example, AI anomaly detection results automatically trigger evidence storage; contract number parsing results provide the initial business context for evidence storage. This interaction ensures the timeliness, accuracy, and business relevance of evidence storage, forming an automated and secure closed loop where evidence storage occurs as soon as a business operation happens. The blockchain evidence storage mechanism is no longer a security accessory independent of the business system, but an inherent security capability deeply embedded in the entire intelligent elevator control system and integrated with the business flow, achieving a balance between security, reliability, and business efficiency.
[0049] Key operations are recorded on the blockchain. At critical nodes such as successful site creation, device malfunction, and completion of maintenance, structured log records are automatically generated. The log record format is: {Evidence ID, Device MAC address, Operation type, Operation time, Operation content, Operator employee number}.
[0050] Hash-based evidence storage involves performing SHA-256 hash operations on log records, with a hash value length of 64 bits. The Hyperledger Fabric consortium blockchain is deployed locally, with node configurations of three types: park operation and maintenance center nodes, elevator manufacturer nodes, and third-party audit institution nodes. The consensus mechanism is the Raft protocol, with block generation intervals of 10 seconds for evidence storage, and strong association with the unique identifier of the device.
[0051] Trusted traceability verification provides a query interface via evidence storage ID or device ID. The request method is: GET / api / v1 / blockchain / query, with parameters: evidence storage ID / device MAC. By comparing the hash value on the chain with the hash value recalculated from the business data, the authenticity and integrity of the record are verified. If the hash values match, the record is trustworthy; if they do not match, the record has been tampered with.
[0052] S106. Establish three types of edge emergency response mechanisms: Edge gateway fault redundancy is implemented with a primary / backup hot standby mechanism. The primary gateway sends a heartbeat signal to the backup gateway every 500ms. If the backup gateway fails to receive the heartbeat signal three times consecutively, it determines that the primary gateway has failed. Based on the locally cached acquisition configuration and model parameters, it automatically takes over the acquisition and inference tasks of the primary gateway. After the primary gateway recovers, the backup gateway returns the tasks to the primary gateway through incremental synchronization, that is, only synchronizing the new data and model updates during the failure period, to avoid data loss.
[0053] For sudden power outages, the edge gateway has a built-in emergency battery that triggers an instantaneous data writing mechanism to Flash after a power outage. This mechanism writes the original data and feature data from the 10 seconds prior to the power outage into the local Flash memory. After power is restored, the system automatically reads the Flash data and retransmits it to the cloud, ensuring no data loss at the millisecond level.
[0054] Multi-building scenario adaptation: Providing scenario-based configuration templates to meet the differentiated needs of different building types. Residential buildings: Low data collection frequency with a collection cycle of 200ms, low model update frequency with a model fine-tuning cycle of 14 days, and implementation of a high privacy protection strategy with differential privacy ε=0.3; Commercial complex: High data collection frequency with a collection cycle of 50ms, high model update frequency with a model fine-tuning cycle of 7 days, and implementation of privacy protection strategies with differential privacy ε=0.5; Office buildings: Medium data acquisition frequency with a data acquisition cycle of 100ms, medium model update frequency with a model fine-tuning cycle of 10 days, and medium privacy protection strategy with differential privacy ε=0.5.
[0055] In some implementations, corresponding to the aforementioned application function implementation method embodiments, this application also provides a building full-link elevator control intelligent system and corresponding embodiments.
[0056] See Figure 2 A building-wide intelligent elevator control system, comprising: Based on a five-level end-to-end architecture, edge emergency response mechanism, and full-process business logic, the system can be divided into 7 functional layers + 1 basic support layer. Each layer contains specific functional modules, covering the entire chain of capabilities from business-driven to secure evidence storage, as detailed below: The Business-Driven and Site Management Layer addresses pain points such as low site creation efficiency, rigid templates, and offline data loss. As the system's business entry point and basic configuration hub, it comprises five core modules: The contract number parsing and information association module receives and parses fixed-format elevator contract numbers, and automatically associates them with customer ID, building type, number of elevators, equipment model and other information through API, realizing the initial mapping between business credentials and digital information.
[0057] The automatic site creation module replaces the traditional manual Excel import, shortening the site creation time. It uses the Snowflake algorithm to generate unique site IDs and automatically completes device grouping and administrator account creation simultaneously, without manual intervention.
[0058] The scenario-based configuration recommendation module, based on historical configuration data cached in Redis, uses an item-based collaborative filtering algorithm to recommend personalized service types, device grouping strategies, and permission granularity for newly created sites.
[0059] The dynamic business rule verification module integrates the Drools rule engine, presets two types of core verification rules, and returns specific repair suggestions when verification fails. This is used to supplement the verification capability of implicit business rules and avoid configuration errors.
[0060] The offline synchronization and caching module temporarily stores site configurations and operation logs in the mobile device's database when the network is interrupted; after the network is restored, atomic synchronization is achieved through the interface to ensure that offline operations are not lost.
[0061] The edge sensing and data preprocessing layer, designed to achieve millisecond-level data perception and reduce bandwidth consumption, serves as the system's data input and preprocessing hub. Relying on edge gateway hardware, it comprises five modules: The edge gateway hardware unit, as the core hardware on the edge side, supports primary, backup, and hot standby, and is equipped with extended MQTT protocol parsing and lightweight computing capabilities. It serves as the physical carrier for data acquisition, preprocessing, and local inference.
[0062] The millisecond-level streaming acquisition module, based on the extended MQTT protocol, adds two new fields: acquisition period and device status flag. It subscribes to the elevator's raw data, including device current, door control status, and card reader signal, at a minimum period of 100ms.
[0063] The streaming data preprocessing module uses a sliding window weighted filtering algorithm to suppress noise in the raw data, ensuring data stability and improving the accuracy of subsequent feature extraction and AI detection.
[0064] The key feature extraction module calculates three core features in real time: 5-second current variance, door switch response time, and number of consecutive card reading failures. These features provide input features for AI anomaly detection, focusing on key features with high fault correlation and reducing redundant data.
[0065] The data compression and transmission optimization module adopts a hybrid mechanism of abnormal triggering and periodic reporting. When the feature value exceeds the normal range or reaches the 1-minute period, the feature data is uploaded after being compressed by GZIP, reducing bandwidth usage by more than 60%, balancing real-time performance and bandwidth costs, and avoiding the uploading of the entire data.
[0066] The intelligent detection and model self-evolution layer, designed to address issues such as high false alarms and missed alarms, and model incompatibility with aging equipment, serves as the system's intelligent decision-making hub and comprises four modules: The lightweight AI model deployment module loads a time-series fusion Transformer model quantized with INT8 integers onto the edge gateway, adapting to the limited computing power on the edge side, enabling local edge inference and reducing reliance on the cloud.
[0067] The real-time edge inference module takes a feature sequence as input and completes inference within 10ms, accurately identifying anomalies such as motor overload, gate jamming, and intermittent card reader interruption, replacing fixed threshold warnings and reducing false alarms and missed alarms.
[0068] The multi-channel real-time early warning module detects an anomaly and pushes it to the operation and maintenance platform in real time via WebSocket. At the same time, it also pushes alarm information and data screenshots via SMS / APP to ensure that operation and maintenance personnel can respond quickly, realize the anomaly-early warning closed loop, and reduce the amount of ineffective operation and maintenance work.
[0069] The model local adaptive module automatically fine-tunes the model parameters using hourly feature data within a set time period if the device does not issue any abnormal warnings for a continuous set time period. This adapts to the performance drift caused by device aging, enabling the model to self-evolve and avoiding frequent manual parameter adjustments.
[0070] The Federated Collaborative Optimization Layer, designed to balance data collaborative optimization with privacy compliance, serves as the central hub for the system's global model upgrades and comprises five modules: The edge-side model parameter calculation module automatically calculates the weight difference ΔW between the local model and the current global model at 00:00 on the 1st of each month. This provides basic data for federated aggregation and enables parameter-level collaboration that allows data to remain within the building.
[0071] The differential privacy protection module adds Laplace noise to the weight difference to meet differential privacy requirements, avoids inferring the original sensitive data through parameters, and solves the pain point of data sharing privacy risks.
[0072] The cloud-based federated aggregation server deploys the FedAvg algorithm, calculates weighting coefficients based on the number of elevators in each building, and aggregates the weighted differences uploaded by each edge gateway after noise has been added, generating a new version of the global model. This enables the convergence of knowledge from multiple buildings and improves the performance of the global model.
[0073] The global model encryption and distribution module uses AES-256 encryption to encrypt the new version of the global model and distributes it to each edge gateway through a dedicated encrypted channel to ensure the security of the model transmission process, prevent tampering or theft, and ensure the security of the model update link.
[0074] The edge model update module receives the encrypted global model from the edge gateway, decrypts it, and overwrites the local old model, completing the closed loop of global optimization → edge implementation. This achieves a common improvement in the performance of the entire system's models, forming a self-evolutionary cycle of edge local adaptation → federated global optimization.
[0075] The blockchain secure evidence storage layer, designed to meet the traceability requirements of Level 3 Information Security Protection, serves as the system's trusted auditing hub and actively collaborates with other layers. It comprises five modules: The structured log generation module automatically generates structured logs at key nodes, ensuring that the logs are closely related to business logic.
[0076] The SHA-256 hashing module performs SHA-256 hashing on structured logs to generate an immutable log digest, providing a foundation for subsequent on-chain evidence storage, ensuring the integrity of log content, and preventing repudiation after tampering.
[0077] The Hyperledger Fabric consortium blockchain node cluster deploys nodes from the park's operation and maintenance center, elevator manufacturers, and third-party auditing agencies. It adopts the Raft consensus mechanism to form a trusted evidence storage network, avoiding the risk of tampering by a single node, replacing general-purpose blockchain evidence storage, and enabling scenario-based customization.
[0078] The blockchain evidence storage module writes the hash digest and the device's unique identifier into the consortium blockchain. It also supports automatic evidence storage triggered by AI anomaly detection and site-created context-related evidence storage, enabling proactive linkage between evidence storage and business flow. This avoids evidence storage becoming an independent security attachment and embeds it into the entire business logic.
[0079] The Trusted Traceability and Verification module provides a query interface. By comparing the hash value on the chain with the hash value recalculated from the business data, it verifies the authenticity of the record, realizes cross-entity penetration audit, meets the Level 3 Information Security Protection Requirements, and clarifies the responsibilities across the entire chain.
[0080] The edge emergency backup layer, designed to enhance robustness in complex industrial scenarios, serves as the system's fault tolerance hub and comprises three modules: The primary / backup gateway hot standby module configures a backup gateway for the primary edge gateway. The primary gateway sends a heartbeat signal to the backup gateway every 500ms. If the backup gateway fails to receive a heartbeat three times consecutively, it determines that the primary gateway has failed and takes over the data acquisition and inference tasks within 1.5 seconds. After the primary gateway recovers, the backup gateway returns the tasks through incremental synchronization, with no data loss, thus solving the single point of failure problem of the edge gateway.
[0081] The sudden power outage data protection module features an edge gateway with a built-in emergency battery. After a power outage, a millisecond-level instantaneous data writing mechanism is triggered to write the original data and feature data from the 10 seconds prior to the power outage to the local Flash memory. Upon power restoration, the Flash data is automatically read and retransmitted to the cloud, ensuring no data loss at the millisecond level and mitigating the risk of data corruption caused by sudden power outages.
[0082] The multi-building scenario adaptation module offers three preset scenario-based configuration templates to suit different building requirements: For residential buildings, the data collection period is 200ms, the model fine-tuning period is 14 days, and the differential privacy ε=0.3. Commercial complex, data collection period 50ms, model fine-tuning period 7 days, differential privacy ε=0.5; Office building, data collection period 100ms, model fine-tuning period 10 days, differential privacy ε=0.5; Avoid a one-size-fits-all configuration and adapt to different use cases.
[0083] The User Interaction and Operations Layer, supporting operations and maintenance personnel in system management, serves as the central hub for human-computer interaction and comprises two modules: The operations and maintenance management platform provides a visual interface and supports functions such as site configuration management, real-time data monitoring, anomaly alert viewing, federated model progress tracking, and blockchain evidence storage and auditing. It serves as the core operation entry point for operations and maintenance personnel, integrating data across the entire chain to improve operations and maintenance efficiency.
[0084] The mobile operation and maintenance terminal module, based on an industrial PAD, supports offline site creation, abnormal alarm reception, and operation and maintenance record submission. It is adapted to on-site mobile operation scenarios, supplements offline mobile operation and maintenance capabilities, and covers on-site scenarios.
[0085] The basic support layer, to ensure the stable operation of the entire system, is the underlying support hub of the system and consists of three modules: The multi-protocol communication module supports protocols such as RESTful API, WebSocket, extended MQTT, and TLS 1.3, enabling secure communication between modules at different layers and solving the problem of heterogeneous communication among multiple modules.
[0086] The tiered storage module integrates multiple storage media to meet the needs of different scenarios, balancing storage performance and data security. Local storage includes SQLite mobile terminal offline data, Flash gateway power failure data, and Redis configuration cache; cloud storage includes global models and historical operation and maintenance data; and on-chain storage includes hash digest Hyperledger Fabric. The access control module binds user permissions based on the site ID, supports upper limit control of employee ID permissions to ensure operational compliance, and works in conjunction with the business rule verification module to prevent unauthorized operations.
[0087] In some implementations, corresponding to the aforementioned application function implementation methods and system embodiments, this application also provides a specific embodiment.
[0088] The following is a detailed deployment case study of three office buildings (A, B, and C) in a certain industrial park. Each building has 10 floors and 10 elevators. The system is equipped with an edge gateway, and the operation and maintenance mobile devices (industrial PADs) are running Android 12 and have a built-in SQLite database.
[0089] Site creation: Maintenance engineer Zhang was operating an industrial PAD in the lobby of Building A when the on-site network became unstable, with bandwidth fluctuating between 1-5 Mbps, and the system automatically entered offline mode. Enter contract number HT20240520A01, where HT20240520 is the date, A0 is the area code of Building A, and 01 is the serial number. The system will identify the customer information through the local Redis cache: customer name: a certain operating company, building type: office building, number of elevators. The system recommends the following based on the Item-Based collaborative filtering algorithm: elevator control + energy consumption monitoring, 10 devices / group, permission granularity: administrator Zhang, employee ID Z001 + 2 maintenance personnel, Zhang can accept with one click; Drools rule engine offline verification: Employee ID Z001 currently has 2 bound sites, contract number area code A0 matches building A, verification passed; The system uses the Snowflake algorithm to generate site ID ZG-A-001 and automatically creates a device group with group ID ZG-A-G01, containing 10 elevators; the administrator account is Zhang San, with permissions for site configuration modification and exception handling approval; all data is temporarily stored in the SQLite database of the PAD. After 30 minutes, the network was restored, and the system atomically synchronized the data through the POST / api / v1 / sync / offlineData interface. The synchronization was successful on the first attempt, and the entire process took about 4 minutes.
[0090] Real-time monitoring and early warning: The edge gateway in Building A collects elevator data at 100ms intervals, configured with a sliding window weighted filter, with a window size of 5 seconds. At 14:30 on a certain day, the current of elevator No. 5 surged from the normal baseline of 12A to 16A. The system calculated the current variance over 5 seconds to be 9.2A², which is outside the normal range of <5A², triggering an anomaly detection. The edge gateway loads a time-series fusion Transformer model with INT8 integer quantization algorithm. Given a feature sequence of nearly 30 seconds, including current, gating status, and card reader signal, it infers motor overload within 15ms with a confidence level of 95%. The system pushes the information to the operation and maintenance platform in real time via WebSocket, showing that the motor of elevator No. 5 is overloaded with a confidence level of 95% and the time of occurrence is 14:30:02. It also sends a text message to Zhang: "Alert! The motor of elevator No. 5 in Building A of a certain park is abnormal. [Click to view the current curve]". At the same time, the APP pushes the same content and a screenshot of the current curve in the past 30 seconds. After Zhang San confirms the alarm via the APP, the system automatically records "Alarm confirmation time 14:30:15, confirmer Z001" and temporarily stores the record locally until it is uploaded to the blockchain later.
[0091] Model co-evolution: Buildings A, B, and C are each equipped with 10, 10, and 8 elevators respectively, participating in federated collaborative optimization: At 00:00 on the 1st of the following month, the edge gateways of the three buildings respectively calculate the weight difference between the local model and the global model. , , After adding Laplace noise, the data is uploaded via TLS 1.3 encryption, with each gateway uploading approximately 8KB of data. The cloud-based federated server uses the FedAvg algorithm to calculate the weighting coefficients: The weighted aggregation generates a new version of the global model; The new model was encrypted with AES-256 and then sent to the three building gateways. After the building gateway updated the model, it successfully identified the intermittent card reader failure that had occurred in building B. The detection rate of this type of fault increased from 75% before the upgrade to 90%, an improvement of 15%.
[0092] End-to-end security audit: All key operations of elevator No. 5 in Building A have been recorded using blockchain technology. The system automatically generated three nodes: site creation successful (14:34), elevator motor malfunction occurred (14:30), and maintenance completed (15:20, result: motor bearing replaced, normal operation restored). The system automatically generated the following structured log: {Evidence ID: BC_Proof_ZG-A-001_20241027_001, Device MAC: 00:1B:44:11:3A:B7, Operation type: Device malfunction, Operation time: 2024-10-27 14:30:02, Operation content: Motor overload (current variance 9.2A²), Operator employee number: System automatic}; The logs are hashed using SHA-256, with the hash value: 7a2f9d3e8b1c4e5a6f7d8e9b0c1d2e3f4a5b6c7d8e9f0a1b2c3d4e5f6a7b8c9d. They are then stored on the Hyperledger Fabric consortium blockchain, with nodes including a park operations and maintenance center, an elevator manufacturer, and a third-party auditing firm. Three months later, a security audit was conducted. The auditors called the query interface through the evidence storage ID "BC_Proof_ZG-A-001_20241027_001". The hash value on the chain was consistent with the hash value recalculated from the business data. The entire chain record was true and accurate, the responsibilities were clear, and the operators, processing procedures, and time nodes were traceable.
[0093] Edge emergency scenario verification: During the deployment in Building A, two types of emergency scenarios were simulated: Gateway failure: The main gateway IP: 192.168.1.100 suddenly lost network access. The backup gateway IP: 192.168.1.101 failed to receive heartbeat signals for 3 consecutive times and took over the data collection task within 1.5 seconds. It continued to collect data from elevator No. 5 based on the local cache configuration. The main gateway recovered after 10 minutes, and the backup gateway incrementally synchronized the feature data within 10 minutes. There was no data loss. Sudden power outage: When a sudden power outage occurs in Building A, the edge gateway's emergency battery activates and writes the current data from the 10 seconds prior to the power outage into the Flash memory within 100ms. After power is restored, the data is automatically read and retransmitted, with a 100% success rate in retransmission.
[0094] The various embodiments of this application have been described above. These descriptions are exemplary and not exhaustive, nor are they limited to the disclosed embodiments. Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the described embodiments. The terminology used herein is chosen to best explain the principles, practical application, or improvement of the technology in the market, or to enable others skilled in the art to understand the embodiments disclosed herein.
Claims
1. A building-wide elevator control method, characterized in that, include: Receive and parse the elevator contract number, associate customer and building information based on the contract number, generate a unique station identifier, and perform equipment grouping and initial permission configuration; Perform offline synchronization configuration, cache site configuration data on the mobile terminal, and perform atomic synchronization operation after the network is restored; Real-time data acquisition at the edge: The raw data stream of elevator operation is periodically collected through the edge gateway, and the raw data stream is filtered and preprocessed in real time to extract key feature data. A lightweight AI model is deployed on the edge gateway to perform real-time inference based on the key feature data, identify device anomalies, and trigger multiple real-time warnings. When the device operates normally for a continuous set period of time, the local model parameters are fine-tuned using the data from that period to achieve local model adaptation. Each edge gateway periodically calculates the parameter difference between the local model and the global model, adds noise that meets differential privacy requirements to the parameter difference, and then uploads it to the cloud federated server. The cloud federated server performs weighted aggregation on the encrypted parameter difference based on the number of devices in each building, generates a new version of the global model, and securely distributes it to each edge gateway for updates. At key business nodes such as successful site creation, device malfunction, and completion of operation and maintenance, structured logs are generated, the hash value of the logs is calculated, and the hash value is associated with the device identifier and written into the blockchain for evidence storage. It provides query and verification interfaces based on evidence storage identifiers or device identifiers to achieve reliable traceability of the entire operation chain.
2. The building end-to-end elevator control method according to claim 1, characterized in that, The generation of a unique site identifier includes: The elevator contract number is parsed into a fixed format, which is: HT + 4-digit year + 2-digit month + 2-digit day + 2-digit area code + 2-digit serial number; The API automatically associates customer ID, building type, number of elevators, and equipment model information to achieve the initial mapping between business credentials and digital information, and associates and populates customer information and building type. The Snowflake algorithm is used to generate unique site IDs, with the generation rule being: area abbreviation + building number + 3-digit serial number; At the same time, device groups and administrator accounts are created, and the initial permissions of the administrator accounts are bound to the corresponding sites.
3. The building end-to-end elevator control method according to claim 1, characterized in that, The generation of a unique site identifier also includes: Based on historical configuration data cached in Redis, the similarity is calculated using an Item-Based collaborative filtering algorithm to recommend personalized service types, device grouping strategies, and permission granularities for newly created sites. Integrate the Drools rule engine to perform dynamic business rule verification and pre-set core business rules for the upper limit of the number of sites bound to the employee ID and the consistency of the contract number region.
4. The building end-to-end elevator control method according to claim 1, characterized in that, The real-time filtering preprocessing of the original data stream and the extraction of key feature data include: The edge gateway subscribes to and collects raw data streams of device current and card reader signals at a minimum period of 100ms via the extended MQTT protocol. Sliding window weighted filtering is used to suppress noise; Real-time calculation of three key features: 5-second current variance, door switch response time, and number of consecutive card reading failures; A hybrid mechanism of abnormal triggering and periodic reporting is adopted to upload compressed feature data, thereby reducing bandwidth usage.
5. The building end-to-end elevator control method according to claim 1, characterized in that, The deployment of the lightweight AI model on the edge gateway includes: The edge gateway loads a time-series fusion Transformer model with INT8 integer quantization algorithm to adapt to the limited computing power on the edge side, realize local edge inference, and accurately identify motor overload, gate jamming, and intermittent card reader interruption. Upon detecting an anomaly, the system pushes the data to the operations and maintenance platform in real time via WebSocket, and also sends alarm information and related data graphs via SMS / APP. If the equipment operates normally for 7 consecutive days, the model parameters will be automatically fine-tuned using the data from that period to adapt the model to the aging and performance drift of the equipment.
6. The building end-to-end elevator control method according to claim 1, characterized in that, The cloud-based federated server performs a weighted aggregation of the encrypted parameter differences based on the number of devices in each building, including: The cloud-based federated server uses the FedAvg algorithm to perform weighted aggregation based on the number of devices in each building, generating a new global model. The formula for calculating the weighting coefficients is as follows: (2) In the formula, Let be the weighting coefficient for the i-th building. Let be the number of elevators in building i. The total number of all building facilities participating in the federation; The encrypted new global model is distributed to each edge gateway through a dedicated channel. After the gateway decrypts the data, it updates its local model, thus improving the performance of the model by ensuring that the data stays within the building.
7. The building end-to-end elevator control method according to claim 1, characterized in that, The implementation of trusted traceability for the entire operation includes: At key points such as successful site creation, device malfunction, and completion of operation and maintenance, structured logs are generated to ensure that the logs are closely related to business logic. The log format is: evidence ID, device MAC address, operation type, operation time, operation content, and operator employee number. The structured logs are hashed using SHA-256, with a hash value length of 64 bits, to generate an immutable log digest, providing a basis for subsequent on-chain evidence storage and ensuring the integrity of the log content. Deploy a Hyperledger Fabric consortium blockchain node cluster locally, deploying three types of consortium blockchain nodes: park operation and maintenance center nodes, elevator manufacturer nodes, and third-party audit institution nodes. Adopt the Raft consensus mechanism to form a trusted evidence storage network, avoid the risk of tampering by a single node, replace general blockchain evidence storage, and realize scenario-based customization. After strongly associating the hash digest with the device's unique identifier, it is written into the consortium blockchain, supporting automatic evidence storage triggered by AI anomaly detection and site-created context-associated evidence storage, thus realizing proactive linkage between evidence storage and business flow. It provides an interface to query the evidence storage ID or device MAC address. By comparing the hash value on the consortium blockchain with the hash value recalculated from the business data, it verifies the authenticity of the record, realizes cross-entity penetration audit, meets the requirements of Level 3 Information Security Protection, and clarifies the responsibilities of the entire chain.
8. The building end-to-end elevator control method according to claim 1, characterized in that, Also includes: Three types of emergency response plans for the edge: Edge gateway fault redundancy is implemented, with a primary and backup gateway hot standby mechanism configured. The primary gateway sends a heartbeat signal to the backup gateway every 500ms. If the backup gateway fails to receive the heartbeat signal three times in a row, it is determined that the primary gateway has failed and will automatically take over the data collection and inference tasks of the primary gateway. After the primary gateway recovers, the backup gateway returns the task to the primary gateway through incremental synchronization to avoid data loss. For sudden power outages, the edge gateway has a built-in emergency battery. After a power outage, it triggers a mechanism to instantly write data to Flash, writing the original data and feature data from the 10 seconds before the power outage to the local Flash memory. After power is restored, the system automatically reads the data from the Flash memory and retransmits it to the cloud, ensuring no data loss at the millisecond level. Multi-building scenario adaptation: Providing scenario-based configuration templates to meet the differentiated needs of different building types. For residential buildings, a low data collection frequency and a low model update frequency are adopted, and a high privacy protection strategy is implemented. Commercial complexes employ high data collection frequency and high model update frequency, while implementing privacy protection strategies. For office buildings, a medium data collection frequency and a medium model update frequency are adopted, and a medium privacy protection strategy is implemented.
9. A building end-to-end elevator control intelligent system, used to execute the building end-to-end elevator control method according to any one of claims 1-8, characterized in that, include: The business-driven and site management layer is used to receive and parse elevator contract numbers to achieve automated site creation, scenario configuration recommendation, business rule verification, and offline data synchronization. The edge awareness and data preprocessing layer, deployed on the edge gateway, is used for millisecond-level data acquisition, streaming data preprocessing, key feature extraction, and data transmission optimization. The intelligent detection and model self-evolution layer is deployed on the edge gateway to load lightweight AI models for real-time anomaly detection, trigger immediate warnings, and achieve local adaptive updates of the model. The federated collaborative optimization layer, including the cloud federated server, is used to aggregate the model parameter differences of each edge gateway under the premise of privacy protection, and generate and distribute a new version of the global model. The blockchain security storage layer is used to generate structured logs at key business nodes, calculate hash values and write them to the blockchain, providing trusted traceability and verification functions; The edge emergency protection layer is used to realize the primary and backup hot standby of the edge gateway, data protection in case of sudden power failure, and differentiated configuration adaptation for multi-building scenarios.
10. The building end-to-end intelligent elevator control system according to claim 9, characterized in that: The business drivers and site management layer include: The contract number parsing and information association module is used to receive and parse elevator contract numbers into a fixed format, and automatically associate customer and building information through API to realize the initial mapping between business vouchers and digital information. The automatic site creation module generates unique site IDs using the Snowflake algorithm and simultaneously completes device grouping and administrator account creation. The scenario-based configuration recommendation module recommends personalized service types, device grouping strategies, and permission granularity for newly created sites based on historical configuration data and through an item-based collaborative filtering algorithm. The dynamic business rule verification module integrates the Drools rule engine and presets core verification rules. The offline synchronization and caching module temporarily stores site configurations and operation logs in the mobile device's database when the network is interrupted; after the network is restored, atomic synchronization is achieved through the interface. The edge sensing and data preprocessing layer includes: The edge gateway hardware unit, as the core hardware on the edge side, supports primary and backup hot standby and is equipped with extended MQTT protocol parsing and lightweight computing capabilities; The millisecond-level streaming acquisition module, based on the extended MQTT protocol, subscribes to the elevator's raw data at a minimum period of 100ms. The streaming data preprocessing module uses a sliding window weighted filtering algorithm to suppress noise in the raw data. The key feature extraction module calculates the 5-second current variance, door switch response time, and number of consecutive card reading failures in real time, providing input features for AI anomaly detection. The data compression and transmission optimization module adopts a hybrid mechanism of abnormal triggering and periodic reporting, and uploads feature data through GZIP compression to avoid uploading the full data. The intelligent detection and model self-evolution layer includes: The lightweight AI model deployment module loads the time-series fusion Transformer model on the edge gateway, adapting to the limited computing power on the edge side and enabling local edge inference. The real-time edge inference module, by inputting feature sequences, accurately identifies anomalies such as motor overload, gate jamming, and intermittent card reader disconnection. The multi-channel real-time early warning module detects an anomaly and pushes it to the operation and maintenance platform in real time via WebSocket, while also linking SMS / APP to push alarm information and data screenshots; The model local adaptive module fine-tunes the model parameters using the feature data of that period if there are no abnormal warnings for the equipment within a continuous time period, in order to adapt to the performance drift caused by equipment aging. The federated collaborative optimization layer includes: The edge-side model parameter calculation module automatically calculates the weight difference between the local model and the current global model for each edge gateway, providing basic data for federated aggregation. The differential privacy protection module adds Laplace noise to the weight difference to meet differential privacy requirements. The cloud-based federated aggregation server deploys the FedAvg algorithm, calculates weighting coefficients based on the number of elevators in each building, and aggregates the weight differences uploaded by each edge gateway to generate a new version of the global model, thereby improving the performance of the global model. The global model encryption and distribution module uses AES-256 to encrypt the new version of the global model and distributes it to each edge gateway through a dedicated encrypted channel. The edge model update module decrypts and overwrites the local old version of the global model, thereby improving the overall model performance of the entire system. The blockchain security storage layer includes: The structured log generation module automatically generates structured logs at key nodes, ensuring that the logs are closely related to business logic; The SHA-256 hashing module performs SHA-256 hashing on structured logs to generate an immutable log digest. The Hyperledger Fabric consortium blockchain node cluster deploys nodes from the park's operation and maintenance center, elevator manufacturers, and third-party auditing agencies. It adopts the Raft consensus mechanism to form a trusted evidence storage network, replacing general-purpose blockchain evidence storage and enabling scenario-based customization. The blockchain evidence storage writing module writes the hash digest and the device's unique identifier into the consortium blockchain. It also supports automatic evidence storage triggered by anomaly detection and evidence storage related to site creation context, enabling proactive linkage between evidence storage and business flow, and embedding full-link business logic. The trusted traceability and verification module provides a query interface to verify the authenticity of records by comparing the hash value on the chain with the hash value recalculated from the business data, thereby meeting the requirements of Level 3 Information Security Protection and clarifying the responsibilities across the entire chain. The edge emergency protection layer includes: The primary / backup gateway hot standby module configures a backup gateway for the primary edge gateway. The primary gateway sends a heartbeat signal to the backup gateway every 500ms. If the backup gateway fails to receive heartbeats for three consecutive times, it takes over the data acquisition and inference tasks within 1.5 seconds. After the primary gateway recovers, the backup gateway returns the tasks through incremental synchronization, thus solving the single point of failure problem of the edge gateway. The sudden power outage data protection module has an emergency battery built into the edge gateway. After a power outage, it triggers a mechanism to instantly write data to Flash, writing the original data and feature data from the 10 seconds before the power outage to the local Flash. After power is restored, it automatically reads the Flash data and retransmits it to the cloud, thus addressing the risk of data loss due to sudden power outages. The multi-building scenario adaptation module has three preset scenario-based configuration templates for residential buildings, commercial complexes, and office buildings to adapt to different building needs.