Zero-code intelligent building operation and maintenance platform, system and storage medium

Abstract

This invention relates to the field of building information management technology, and discloses a zero-code smart building operation and maintenance platform, system, and storage medium, including an IaaS infrastructure layer, a PaaS engine and component layer, a SaaS application configuration layer, and a multi-terminal application presentation layer. The PaaS engine and component layer includes a business model driving engine, an atomic component library, a rule engine, and a digital twin fusion module, used for performing model parsing, system linkage, and 3D fusion. The SaaS application configuration layer receives visual configuration instructions and serializes them into standard structured text. The multi-terminal application presentation layer parses the text into an operation interface and establishes communication links. This invention directly drives business processes through the serialization of configuration instructions, combined with dynamic scheduling of concurrent events and a rendering strategy based on viewpoint distance, reducing the development threshold of the system and improving operational stability and 3D scene rendering efficiency in high-concurrency environments.

Description

Technical Field

[0001] This invention relates to the field of building information management technology, and in particular to a zero-code smart building operation and maintenance platform, system and storage medium. Background Technology

[0002] With the development of building information modeling (BIM) and Internet of Things (IoT) technologies, smart building operation and maintenance (O&M) systems are increasingly being used in modern building management. Currently, smart building O&M platforms primarily rely on traditional code-level custom development, resulting in strong code coupling between various business modules and underlying logic within the system architecture. When building management needs to add new equipment monitoring types, adjust cross-subsystem linkage rules, or change business approval interfaces, professional developers are typically required to modify the source code and recompile and redeploy the system. This heavy reliance on manual coding leads to slow response times to business needs and high system maintenance costs in the later stages.

[0003] At the underlying data access and processing level, sensors and intelligent control devices deployed in the building's intranet continuously send status data to the server. Existing systems mostly employ static thread resource allocation and conventional first-in-first-out (FIFO) queue mechanisms to handle these high-frequency concurrent requests. This fixed task processing logic lacks the ability to dynamically assess business complexity and current system load. When encountering sudden, widespread device anomalies or high-frequency retries due to network fluctuations, system computing resources are easily exhausted by low-value routine reporting data, leading to the blocking of processing threads for critical alarm events such as fire and security incidents, thus affecting the reliability of system operation.

[0004] At the front-end business display level, integrating 3D building information models with equipment operation data has become an industry trend. Digital twin scenes of large buildings typically contain massive amounts of spatial components and high-precision textures. Current system rendering mechanisms largely rely on the underlying graphics interface pipeline, lacking rendering scheduling strategies tailored to business characteristics. In actual operation, fully loading the scene often leads to memory overflow and screen stuttering on the front-end display terminal; while using only a simple spatial distance culling algorithm easily filters out critical equipment components located far from the viewpoint but experiencing severe alarms, failing to balance the visualization needs of sudden business events in building management with the rendering performance limitations of the underlying hardware. Summary of the Invention

[0005] The purpose of this invention is to provide a zero-code intelligent building operation and maintenance platform, system, and storage medium, which solves the problems of long development and iteration cycles, difficulty in data linkage between multiple systems, and limited system operating efficiency and communication stability in complex business scenarios in traditional building operation and maintenance systems.

[0006] To achieve the above objectives, the present invention provides the following technical solution:

[0007] The first aspect of this invention provides a zero-code smart building operation and maintenance platform, comprising:

[0008] The IaaS infrastructure layer provides computing resources, data persistence media, and network communication links.

[0009] The PaaS engine and component layer, deployed on top of the IaaS infrastructure layer, includes a business model-driven engine, a three-layer atomic component library, a visualization rule engine, and a digital twin fusion module. These are used to perform business model parsing, cross-system linkage logic processing, provide modular resources, and perform 3D scene fusion of building information models and business models.

[0010] The SaaS application configuration layer is used to receive input visual configuration instructions and serialize the visual configuration instructions into standard structured text;

[0011] The multi-terminal application presentation layer is used to parse the standard structured text into a terminal operation interface, establish a real-time data link with the server, and output business functions.

[0012] Preferably, the business model-driven engine has a built-in queue-based dynamic scheduling mechanism to handle concurrent events;

[0013] The dynamic scheduling mechanism determines the task execution order by calculating the scheduling priority score of business requests;

[0014] The scheduling priority score is calculated as follows:

[0015] Multiply the predefined event urgency level by its corresponding weight, add the product of the waiting time accumulated in the system queue for the business request and its corresponding time weight, and subtract the degradation penalty factor caused by high-frequency retries.

[0016] The degradation penalty factor is determined based on the number of times the same anomaly is reported consecutively within a preset time window. This mechanism limits the occupation of system scheduling resources by a single high-frequency failure event and balances the execution sequence of concurrent tasks by quantifying the waiting time and the anomaly retry status.

[0017] Preferably, the visualization rule engine performs an execution cost assessment on the rule instance to be processed, calculates the cost assessment value, and distributes the rule instance to the corresponding execution queue.

[0018] The rule instance is transformed from the business rule tree parsed by the visualization rule engine. The calculation method for the computational cost evaluation value of a single rule instance is as follows:

[0019] Multiply the total number of logical nodes contained in the business rule tree by the parsing step constant of a single node, and add the sum of the average response latency costs corresponding to each external data call interface;

[0020] The visualization rule engine allocates the rule instance to a fast execution queue or an asynchronous execution queue according to the magnitude of the calculated overhead evaluation value.

[0021] This method pre-computes the rule execution cost, separates long-time data query tasks and short-time response tasks, and maintains the flow efficiency of the core linkage logic.

[0022] Preferably, the digital twin fusion module includes a dynamic level-of-detail scheduling mechanism based on view point distance;

[0023] The dynamic level-of-detail scheduling mechanism controls the rendering precision by real-time measuring the rendering weight score of the target component in the three-dimensional scene;

[0024] The calculation method of the rendering weight score is as follows:

[0025] Divide the volume of the spatial axial bounding box of the target component by the square of the straight-line spatial distance from the focus of the virtual camera to the center point of the target component, multiply by the screen resolution calibration coefficient, and add a service enhancement compensation value for ensuring the rendering of the warning state component;

[0026] The digital twin fusion module allocates high-precision mesh models, low-polygon mesh models or performs frustum culling on the components in the scene according to the rendering weight score. This scheduling mechanism dynamically allocates three-dimensional rendering resources according to the spatial distance and service status, reducing the graphics calculation load of the presentation layer.

[0027] Preferably, the visualization configuration instruction is used to configure the target page to be published, and the SaaS application configuration layer pre-calculates the expected rendering time of the target page before application release;

[0028] The calculation method of the expected rendering time is as follows:

[0029] Calculate the sum of the products of the maximum depth of the document object model nodes nested inside each visible component in the target page configuration list and the single-node rendering time constant, and then add the product of the basic network latency of the interfaces required for the initialization of the target page and the number of concurrent interface requests;

[0030] When the expected rendering time exceeds the preset fluency threshold, the SaaS application configuration layer intercepts the application release operation, determines the components not in the first-screen visible area in the target page as low-priority components, and adds a lazy loading flag to the low-priority components. This measurement process performs performance verification in the application configuration stage, controlling the initialization loading time of the terminal interface.

[0031] Preferably, the three-layer atomic component library performs a memory overhead assessment on the target page before dynamically loading resources;

[0032] The calculation method for dynamically loaded memory evaluation values ​​is as follows:

[0033] Sum the products of the static resource file sizes of each component referenced by the page and the rendering memory expansion coefficient, and add the product of the deepest level of the dependency chain between nested components within the page and the chain resolution overhead constant.

[0034] When the dynamically loaded memory assessment value exceeds a preset memory limit threshold, an asynchronous lazy loading mechanism is triggered to delay the loading of components in areas not visible on the first screen of the target page. This assessment method combines file size and dependency node depth to control the peak memory usage generated during the component library instantiation phase in complex pages.

[0035] Preferably, the multi-terminal application presentation layer uses the Network Sockets Protocol to establish a full-duplex communication link and has a built-in adaptive heartbeat keep-alive mechanism;

[0036] The adaptive heartbeat keep-alive mechanism dynamically adjusts the sending period of heartbeat probe data packets based on real-time network quality indicators, i.e., the dynamic keep-alive period.

[0037] The dynamic keep-alive period is equal to the preset basic keep-alive period, minus the product of the network round-trip delay time and the delay attenuation coefficient, and then minus the product of the total number of lost communication data packets and the packet loss penalty coefficient.

[0038] When the dynamic keep-alive period is less than the set minimum keep-alive period threshold, the probe is forced to be performed according to the minimum keep-alive period threshold. This mechanism adjusts the probe frequency based on network latency and packet loss indicators to maintain communication connectivity between the terminal and the server in weak network environments.

[0039] Preferably, the multi-terminal application rendering layer includes a virtual long list rendering engine;

[0040] The virtual long list rendering engine calculates in real time the total number of list elements actually participating in rendering within the current screen viewport;

[0041] The total number of list elements is obtained by dividing the absolute height of the visible area by the fixed layout height of a single list data item, rounding up, and then adding the number of elements reserved in the pre-rendering buffer.

[0042] The virtual long list rendering engine generates UI nodes for list elements within the viewport, while reserving in-memory data structures for data outside the visible area without generating UI nodes. This method controls the total number of UI nodes generated when displaying large amounts of data concurrently, reducing memory overhead during data rendering.

[0043] A second aspect of this invention provides a zero-code intelligent building operation and maintenance system, comprising:

[0044] The invention includes a communication interface, a memory, and a processor; the memory is used to store computer programs; when the processor reads and executes the computer programs, it implements the functional interaction and logical flow of the zero-code smart building operation and maintenance platform of any one of the first aspects of the invention.

[0045] A third aspect of the present invention provides a computer-readable storage medium storing a computer program. When the computer program is read and executed by a processor, it realizes the functional interaction and logical flow of the zero-code smart building operation and maintenance platform of any one of the first aspects of the present invention.

[0046] In summary, the present invention has at least one of the following beneficial technical effects:

[0047] 1. This invention constructs a four-layer architecture from the infrastructure layer to the multi-terminal application presentation layer, and introduces a visual component drag-and-drop and model configuration mechanism in the SaaS application configuration layer, directly serializing front-end operation commands into standard structured text. This design based on standard structured text and decoupled interaction of underlying atomic components eliminates the need for source code writing of underlying business logic, enabling operation and maintenance personnel to directly participate in the construction of business applications without modifying the underlying code, reducing the development threshold of smart building operation and maintenance systems, and shortening the deployment and version iteration cycle.

[0048] 2. This invention introduces a dynamic scheduling and execution overhead assessment mechanism into the business model-driven engine and the visualization rule engine. The system determines task scheduling priority by comprehensively calculating the event urgency level, queue waiting time, and degradation penalty factor, and assesses execution overhead based on the number of logical nodes in the business rule tree. This enables the platform to reasonably allocate system computing resources and execution queues when facing massive concurrent anomaly reports from IoT devices or complex cross-system linkage logic, avoiding thread blocking caused by high-frequency concurrent requests and improving the overall operational stability of the platform.

[0049] 3. The digital twin fusion module of this invention adopts a dynamic detail level scheduling mechanism based on viewpoint distance. The platform extracts the spatial bounding box volume of 3D components, calculates their straight-line spatial distance to the virtual camera, and superimposes service enhancement compensation values ​​to calculate the rendering weight score of each component in real time. Based on this score, it automatically performs high-precision rendering, low-polygon replacement, or view frustum culling operations on scene components. This ensures that the core alarm equipment is clearly visible while strictly controlling the video memory overhead of the front-end terminal equipment, thus solving the lag problem during the loading of large building 3D models. Attached Figure Description

[0050] Figure 1 This is a diagram of a zero-code smart building operation and maintenance platform architecture according to an embodiment of the present invention;

[0051] Figure 2 This is a flowchart of a zero-code application lifecycle management method according to an embodiment of the present invention;

[0052] Figure 3 This is a line graph comparing sensor data before and after smoothing processing, provided in an embodiment of the present invention.

[0053] Figure 4 This is a bar chart comparing device disconnection detection time under different network conditions, provided by an embodiment of the present invention. Detailed Implementation

[0054] See attached document Figure 1 This invention provides a zero-code smart building operation and maintenance platform. The platform adopts an architecture combining Software as a Service (SaaS) and Platform as a Service (PAS). From bottom to top, this architecture consists of an IaaS infrastructure layer, a PaaS engine and component layer, a SaaS application configuration layer, and a multi-terminal application presentation layer.

[0055] The IaaS infrastructure layer provides server resources. This layer configures data storage devices. This layer contains network communication facilities. The IaaS infrastructure layer is used to host system operation and provide computing resources.

[0056] The PaaS engine and component layer are deployed on top of the IaaS infrastructure layer. This layer contains the business model-driven engine. This layer has a three-tiered atomic component library. This layer configures a visualization rule engine. This layer integrates a digital twin fusion module.

[0057] The business model-driven engine parses the business model. This engine handles rule flow and process scheduling. It manages data interaction. This engine is compatible with IoT device access.

[0058] The three-layer atomic component library provides modular resources. This library contains basic, general-purpose components. It also contains building-specific components and IoT protocol access components. The components at each layer are structurally decoupled.

[0059] The visualization rules engine receives logical configuration instructions. This engine executes cross-module and cross-system business linkage logic. The digital twin fusion module parses the building information model. This module performs IoT data mapping. This module outputs a 3D scene and controls the visualization interaction.

[0060] The SaaS application configuration layer connects the PaaS engine and the component layer. This layer provides a workbench interface. The workbench includes a model configurator, a component drag-and-drop tool, a configuration workflow designer, and an interface editor and preview / publisher.

[0061] The multi - terminal application presentation layer communicates with the platform backend. This layer includes the web management terminal. This layer includes the mini - program terminal. This layer includes the command large - screen terminal. The multi - terminal application presentation layer calls platform resources according to the parameters of the application configuration layer. This layer renders the application interface and outputs business functions.

[0062] Refer to Appendix Figure 2 , the present invention provides an application management method executed by a zero - code - based intelligent building operation and maintenance platform, which may include the following steps:

[0063] Execute application configuration. The SaaS application configuration layer receives user input instructions. The model configurator configures the data structure of the building business model. The component drag - and - drop tool calls component library resources to establish an interface layout. The interface editor adjusts the interface display form. The process designer determines the business execution process. The visual rule engine defines cross - system linkage logic. The platform converts the above operation instructions into metadata. The platform stores this metadata.

[0064] Execute application preview. The system extracts the stored metadata. The system renders the presentation - layer interface based on the metadata. The system runs the data interaction logic in the preview environment. The system verifies the connectivity of business rules. The system validates the system linkage execution result.

[0065] Execute application release. The platform receives a release confirmation instruction. The business model - driven engine calls the metadata. The engine compiles the metadata into executable code. The platform synchronously deploys the code to the multi - terminal application presentation layer. The code is distributed to the web management terminal, the mini - program terminal, and the command large - screen terminal.

[0066] Execute application iteration. The SaaS application configuration layer receives business update instructions. The platform modifies the corresponding metadata parameters. The platform recompiles and distributes the code. The system overwrites the old - version application nodes. The system maintains the continuity of application operation.

[0067] Execute application operation and maintenance. The PaaS engine and component layer monitor the application running status. The platform collects the data access volume of the multi - terminal application presentation layer. The platform records the device connection status of the Internet of Things protocol access components. The system determines whether the running data exceeds the preset threshold. The system triggers an alarm when the data exceeds the limit. The system records and outputs the running log.

[0068] In this embodiment, the IaaS infrastructure layer provides the basic computing resources, data persistence media, and network communication links for the overall operation of the platform. To support the concurrent invocation of each microservice module and the processing of massive time - series data in the underlying engine layer, the platform deploys servers and configures the network operating environment.

[0069] In embodiments of the present invention, the platform deploys a physical server cluster and allocates computing resources. The deployed physical server cluster carries all computing loads and business scheduling processes within the platform. Specifically, the system establishes a virtualized resource pool through a hardware abstraction layer. Preferably, the virtualization environment uses kernel-based virtual machines or lightweight container clusters. The constructed virtualized resource pool is responsible for allocating independent CPU quotas and runtime memory space to the platform engine and component layers.

[0070] In a real-world operating environment, to prevent a single business module from consuming excessive physical resources and causing the entire platform to crash, the system needs to implement total resource pool control and security boundary isolation. The system pre-calculates the maximum total computing power that can be supplied to upper-layer microservices. To ensure the high-frequency computing stability of the stream processing framework, the calculation rules for the total amount of available computing resources allocated within the resource pool are as follows:

[0071] ;

[0072] In the formula, The total number of available virtual processor cores provided by the system for business microservices; Represents the total number of physical server nodes; Representing the The number of physical cores configured in each physical server; Representing the The computing power allocation coefficient configured for each physical server is used to limit the maximum load level of a single hardware node. Those skilled in the art usually set the allocation coefficient between 0.8 and 0.9 to reserve burst processing space for the physical node. This represents the amount of computing resources reserved for the hardware host operating system and the underlying virtualization management components. The amount of resources reserved is determined based on the minimum operating requirements of the host operating system, and is generally a fixed number of processor cores, such as 2 to 4 cores.

[0073] Furthermore, the platform includes configuration file storage devices and a multimodal database environment. The underlying infrastructure provides persistent storage and caching capabilities adapted to different data characteristics. In specific implementations, the storage environment includes structured relational databases, non-relational databases, and distributed file storage systems.

[0074] In this embodiment, the system deploys a relational database cluster to store business flow data with strong consistency requirements. This business flow data includes attribute dictionary mapping records of business entities, zero-code form data, and metadata records of application model configurations. Simultaneously, the system deploys a non-relational database to handle high concurrency and time-series data read / write requirements. The non-relational database is specifically divided into a key-value in-memory database and a time-series database. The key-value in-memory database is used to reside in the frequently accessed spatial device multi-dimensional mapping matrix and to handle state tree comparison requests for debouncing operators during runtime. The time-series database is used to persistently write operational monitoring parameters continuously reported by IoT devices. Furthermore, the system deploys a distributed file system to store large volumes of unstructured data, including geometric topology source files of the building information model, multimedia rendering materials for the interface, and attachment objects of maintenance forms.

[0075] To ensure data communication quality, the platform establishes network switching equipment and communication protocol support links. The infrastructure layer is configured with load balancers, core switching gateways, and boundary isolation devices. The load balancer, serving as the unified network traffic entry point for the front-end multi-terminal application presentation layer, distributes concurrent access requests to back-end computing nodes for processing. The underlying communication links employ standard Transmission Control Protocol / Internet Protocol (TCP / IP) architectures for packet encapsulation and routing. An independent Virtual Private Network (VPN) is partitioned within the network environment to establish a physical network layer isolation boundary between the building's core business data flow and external public network access traffic, ensuring the network security of the underlying business operating environment.

[0076] In this embodiment, the platform constructs a business model-driven engine at the engine and component layers. The business model-driven engine adopts a four-dimensional driven architecture of model, rules, process, and interface. The engine is responsible for receiving external configuration parameters, performing underlying metadata transformation, and driving the interaction between upper-layer business functions and the digital twin scenario. To achieve application generation and flow under zero-code conditions, the business model-driven engine is constructed and executed.

[0077] In this embodiment, the platform incorporates standardized business models and provides a visual configuration interface. The platform pre-builds six categories of standardized business models for all scenarios, covering personnel and visitor management, parking management, equipment monitoring, energy consumption management, security alarm, and work order maintenance. In this embodiment, each business model includes standardized entities, entity attributes, data relationships, and basic business logic. Taking the equipment monitoring model as an example, the built-in data structure elements include equipment number, equipment type, operating status parameters, parameter thresholds, and fault determination rules.

[0078] Furthermore, in practical applications, operators can customize and extend standardized business models through a visual workbench. The visual configuration mechanism receives configuration commands for attribute extension, rule modification, process binding, and interface association. The system supports adding custom business fields and setting their data types and boundary constraints without modifying the underlying source code.

[0079] In this embodiment, the platform executes model parsing and underlying driving. The business model driving engine parses the visual configuration definition received by the front end into underlying recognizable metadata. In specific implementations, metadata is typically stored using a standard data exchange format (e.g., JSON). The engine reads the structured metadata to complete the initial deployment of the underlying runtime environment. Specifically, the engine calls the relational mapping module to automatically create the corresponding business data table in the relational database and establish primary and foreign key relationships. Simultaneously, the system automatically encapsulates standardized application programming interfaces based on the metadata model to establish data read and write channels. When the terminal triggers a business operation, the engine extracts the metadata, drives the data read and write operations, executes rule verification, and schedules the workflow engine to advance the business process flow.

[0080] In actual building operations, when network fluctuations or sudden anomalies occur, a massive number of IoT devices simultaneously send data reports or alarm requests to the platform. To prevent critical security and fire alarms from being blocked by routine temperature and humidity parameter reports, the business model-driven engine introduces a queue-based dynamic scheduling mechanism when handling concurrent events. The priority of scheduling is calculated as follows:

[0081] ;

[0082] In the formula, The scheduling priority score represents the business request, and the system determines the task execution order based on the descending order of the calculated scores; This represents the predefined urgency level of an event in the business model, with values ​​ranging from 1 to 5, where a larger value indicates a more urgent event. This represents the waiting time that business requests accumulate in the system queue, measured in milliseconds (ms). and This represents the basic weighting coefficient set by the system. Those skilled in the art typically set specific coefficient values ​​based on the system's hardware load. Under normal configurations, the weighting levels... The value is set to 0.7 to 0.8, with time weighting. Set to 0.2 to 0.3 to ensure the dominance of high-priority events while also addressing the starvation of low-priority events; This represents the penalty factor for degradation caused by high-frequency retries. The penalty factor is used to prevent a single IoT device's abnormal reporting request from exhausting the system's scheduling resources. The actual calculation method is to multiply the number of times the device reports the same abnormality consecutively within a preset time window by a fixed decay step size. When the number of reports does not exceed a preset threshold (e.g., 3 times), the penalty factor is 0.

[0083] In this embodiment, the system performs the fusion and interaction between the Building Information Model (BIM) and the business model. Specifically, the business model driving engine has a built-in parser component. The parser component extracts building structure information, equipment physical locations, and spatial geometric attributes from the imported BIM source file. In specific implementation, the system extracts the globally unique identifiers of the 3D model components and establishes a one-to-one mapping association record between the globally unique identifiers and the unique equipment numbers defined in the business model.

[0084] After establishing the mapping relationship, the system establishes a two-way interactive channel at the application presentation layer. On one hand, the system receives mouse click commands from devices in the 3D scene, retrieves and displays the corresponding real-time business data from the database based on the mapping relationship; on the other hand, when the business model-driven engine triggers an alarm rule, the engine sends a positioning command to the 3D rendering component. Based on the mapped device space coordinates, the 3D rendering component automatically adjusts the camera view of the 3D scene to center the target device and changes the rendering color and highlight status of the corresponding model components of the abnormal device, thereby achieving intuitive positioning of the abnormal device.

[0085] In this embodiment, the platform constructs a three-layer atomic component library at the engine and component layers. The component library adopts a metadata definition combined with dynamic rendering model to provide mutually isolated modular resources for building business applications. Based on different business abstraction levels, the platform constructs basic general components, building business-specific components, and IoT protocol access components.

[0086] In this embodiment, the basic general components include text input boxes, drop-down selection boxes, button controls, data tables, visualization charts, and pop-up interactive controls. These basic general components provide the basic display and operation platform for the interface. Furthermore, the platform constructs building-specific components. These building-specific components incorporate dedicated business logic and data interaction capabilities for building management scenarios. Specifically, these building-specific components include a real-time equipment monitoring panel, energy consumption statistics and analysis cards, a security alarm carousel list, a work order processing form, and a personnel access trajectory view.

[0087] To achieve network connectivity for underlying hardware devices, the platform constructs an IoT protocol access component. In this embodiment, the IoT protocol access component incorporates parsing modules for multiple mainstream underlying communication protocols. Specifically, the protocol access modules cover message queue telemetry transmission protocol components, industry standard bus protocol components, open platform unified communication architecture components, and building automation control network protocol components. The IoT protocol access component supports rapid access and time-series data acquisition from building sensors, hardware controllers, and smart terminal devices.

[0088] In this embodiment, the platform implements a decoupling design for various components. Each component constitutes an independent atomic unit and exposes standardized interaction interfaces. These standardized interaction interfaces are specifically divided into attribute injection ports, event throwing channels, and method call channels. There are no direct code-level dependencies between different components; they only publish and subscribe to events through the system bus, thereby achieving physical isolation and free assembly of business components. To achieve component communication in a zero-code environment, the platform generates an event mapping table based on the user's connection operations during the application configuration phase. During application runtime, the system bus intercepts events thrown by the source component, queries the event mapping table, extracts the unique identifier of the target component, and accurately routes the data packet carrying parameters to the target component's method call channel.

[0089] Furthermore, during the application configuration phase, users invoke components via a visual component drag-and-drop interface. The platform provides a configuration canvas interface. Users can drag and drop components, adjust grid layouts, and configure input parameters within this interface. The system supports the same component being referenced repeatedly by multiple business applications or multiple pages. When the platform receives a global instruction to modify the parameters of a specific component, it synchronously updates the content displayed on all related pages by comparing the reference list with the metadata repository.

[0090] During application runtime, the platform maintains a component metadata repository. This repository records the unique identifier, type, version number, and dependencies of each component. Based on the component list configured in the front-end page, the platform dynamically loads associated static resource files at runtime. In large-scale smart building projects, command and control screens typically embed a massive number of video surveillance windows and dynamic charts. Directly loading all components can easily lead to memory overflow and crashes on the front-end devices. Therefore, before dynamically loading resources, the platform pre-evaluates the memory overhead of the target page. The calculation method for the dynamic loading memory evaluation is as follows:

[0091] ;

[0092] In the formula, This represents the estimated memory usage of the target page when all required components are loaded, in megabytes. This represents the total number of components referenced in the page configuration manifest; Representing the The size of the static resource files for each component; The rendering memory bloat factor is used to measure the memory amplification effect during the process of parsing a component from a static file into a document object model tree. Those skilled in the art usually set the bloat factor to be between 2.0 and 3.0. This represents the deepest level of the dependency chain between nested components within the page; This represents the link resolution overhead constant, which is typically 0.5 megabytes per level.

[0093] In this embodiment, when the platform calculates the memory evaluation value When the preset memory limit threshold (e.g., 512 megabytes) is exceeded, the system triggers an asynchronous lazy loading mechanism. The system delays the loading of components in areas not visible on the first screen to ensure the smooth rendering of the business interface.

[0094] Furthermore, the platform supports component-level hot-swapping. When developers need to upgrade a specific building-specific component, the system directly replaces the matching static resource file in the metadata repository. After receiving the version change broadcast, the application presentation layer re-parses the parameters of the target component and binds the underlying data. The platform completes the addition, deletion, and function replacement of local components without restarting the overall business system.

[0095] In this embodiment, the platform constructs a visual rule engine at the engine and component layers. This visual rule engine is responsible for the tree-like parsing and event-driven execution of cross-system and cross-module business linkage logic. The rule engine allows users to define complex business logic through zero-code configuration, enabling automated collaboration between building equipment, business data, and external systems.

[0096] In embodiments of the present invention, the platform acquires the triggering conditions, judgment logic, and execution action parameters input from the front end. Triggering conditions include time-based triggering, device status change triggering, numerical threshold triggering, and manual command triggering. Judgment logic includes logical AND, logical OR, and multiple nested conditional branches. Execution actions include modifying device operating parameters, issuing application notifications, initiating business processes, and calling third-party interfaces.

[0097] Furthermore, the visual rules engine parses multi-dimensional configuration parameters into a bottom-level, flowable business rule tree. In practice, the engine serializes the graphical logical connections received from the front end into a structured logical description file. The business rule tree consists of a root node, condition nodes, and action nodes. To ensure the rigor of the logical flow, the engine performs logic loop detection during the parsing phase. Logic loop detection uses a depth-first traversal algorithm to identify whether there are closed-loop conflicts in the configuration rules. For example, a state change in node A triggers node B, but the action executed by node B in turn modifies the state of node A, thus forming an infinite loop. When a closed-loop structure is detected, the system promptly throws an exception notification to the configuration end.

[0098] In actual building operations, rule execution often involves API calls to multiple external systems. Differences in response speed between these interfaces can easily cause the engine's internal execution threads to be suspended for extended periods. To improve the engine's response efficiency in high-concurrency environments, the system performs load assessment and resource pre-allocation for rule instances to be processed. The calculation method for rule instance execution overhead assessment is as follows:

[0099] ;

[0100] In the formula, An estimated value representing the computational overhead required to execute a single rule instance; This represents the total number of logical nodes contained in the business rule tree; The analytical step size constant representing a single node is typically set between 0.1 and 0.2 by those skilled in the art, depending on the single-core processing capability of the processor. This represents the number of external data call interfaces involved in the corresponding rule; Representing the The average response latency cost of an external data interface is specifically the average response time in milliseconds of the target interface within a preset time period as statistically analyzed by the system log module.

[0101] In this embodiment, the calculated computational cost is evaluated based on the measured computational cost value. The system distributes rule instances to execution queues of different levels. For regular linkage rules with low evaluation values, the system assigns them to the fast execution queue; for rules involving a large number of third-party interface calls or complex data operations, the system assigns them to the asynchronous execution queue and reserves sufficient system handle resources to prevent thread blocking.

[0102] Furthermore, the visualization rules engine invokes the built-in data integration adapter to synchronize interface data between the business subsystem and third-party systems. In this embodiment, the data integration adapter provides standardized protocol conversion capabilities. Specifically, the adapter supports the Representational State Transition Architecture interface, the Remote Procedure Call protocol interface, and database link connections. The adapter performs data format conversion and protocol header encapsulation, realizing bidirectional mapping between the platform's internal business model and the data structures of external heterogeneous systems.

[0103] When executing complex environmental linkage logic, such as automatically adjusting the frequency of the fresh air system based on indoor carbon dioxide concentration, the analog signals collected by the underlying sensors are susceptible to electromagnetic interference, causing glitches and fluctuations. The rule engine uses a built-in smoothing operator to denoise the input signals. This smoothing process prevents frequent start-ups and shutdowns of hardware devices caused by instantaneous fluctuations in sensor signals. The signal smoothing weight coefficient is calculated as follows:

[0104] ;

[0105] In the formula, The weight coefficients representing the smoothing operator are limited to a range of 0 to 1. This represents the standard deviation between the current sampled value of the sensor and its historical mean. This represents the preset allowable fluctuation range of the target sensor's measurement range. Those skilled in the art typically set the fluctuation range based on the sensor's accuracy manual.

[0106] In obtaining weight coefficients Then, the rule engine calculates the effective signal output value used for business rule judgment based on the weight coefficients. The calculation rules for the effective signal output value are as follows:

[0107] ;

[0108] In the formula, This represents the effective signal output value after smoothing. Represents the current instantaneous sampled value of the target sensor; This represents the average operating value of the target sensor over the previous statistical period. The smaller the sampling deviation, the higher the weight of the smoothing operator, and the more the system accepts the current instantaneous sampling value; conversely, the system tends to use the historical average, thereby filtering out abnormal fluctuations and ensuring the stability of the output control commands.

[0109] In this embodiment, the platform constructs a digital twin fusion module at the engine and component layers. This module is responsible for fusing multi-dimensional building business data with a 3D building information model, providing interactive and visualization rendering capabilities based on spatial topology.

[0110] In this embodiment, the platform receives externally imported Building Information Model (BIM) source files. The digital twin fusion module has a built-in lightweight conversion engine that extracts geometric mesh data, material texture resources, and spatial structural attributes from the source files. To establish a binding relationship between physical entities and virtual components, the system extracts a globally unique identifier for each equipment component in the 3D model. Furthermore, the system establishes a one-to-one binding relationship between the globally unique identifier and the equipment asset code defined in the business model in the mapping table. After the binding is completed, the business data flow drives the component state in the 3D scene through the mapping link.

[0111] In this embodiment, the platform performs spatial overlay display of business data in a 3D rendered view. When the business subsystem generates real-time operating parameters or alarm events, the digital twin fusion module retrieves the absolute 3D spatial coordinates of the target device component according to the mapping table. Specifically, the system uses a coordinate transformation matrix to map 3D world coordinates to 2D screen view coordinates and generates a dynamic data information panel at the corresponding position in the view coordinates. When the user performs rotation, scaling, or translation operations in the 3D scene, the system recalculates the coordinate transformation matrix in real time to maintain the visual relative position of the dynamic data information panel and the target device component consistent.

[0112] When loading large-scale intelligent building 3D scenes, full rendering of high-precision components can lead to memory overflow and a sharp drop in frame rate on the front-end device. In this embodiment, the digital twin fusion module introduces a dynamic detail level scheduling mechanism based on viewpoint distance. According to the principle of perspective projection in computer graphics, the visual projection area of ​​a 3D component on a 2D screen is directly proportional to the bounding box volume of the component and inversely proportional to the square of the virtual camera's viewing distance. Components with larger visual projection areas have a more significant impact on the overall visual effect of the scene, thus requiring higher rendering computing power. Based on the above physical perspective principle, the system calculates the rendering weight score of the component in real time based on the current position of the virtual camera and the spatial bounding box volume of the target component. The calculation method for the component rendering weight score is as follows:

[0113] ;

[0114] In the formula, This represents the rendering weight score of the target component in the current rendering frame; The volume of the bounding box representing the spatial axis of the target component, in meters. 3 ; The linear spatial distance from the virtual camera's focus to the center point of the target component is represented in meters (m). This represents the screen resolution calibration factor. Those skilled in the art usually set the factor value based on the pixel density of the display terminal. In a standard 1080P resolution display environment, the resolution calibration factor is usually set to 1.0, while in a 4K resolution environment it is set to between 2.0 and 2.5. The service enhancement compensation value is used to ensure that components that trigger alarm events are not removed from the view frustum by the system. When the device associated with the target component is in a normal state, the service enhancement compensation value is 0. When the target component is in an alarm state, the service enhancement compensation value is set to a preset large value (e.g., 9999) to force the allocation of the highest precision rendering.

[0115] In this embodiment, the system uses the calculated rendering weight score. All components within the scene are sorted in descending order. To precisely control memory consumption, the system sets multiple truncation thresholds. Specifically, the system truncates the top 30% of components and renders them using high-precision mesh models that retain the original polygon count; for components ranked between 30% and 70%, the system automatically replaces the high-precision mesh models with low-polygon mesh models that have undergone polygon reduction; for components ranked below 70%, the system directly performs view frustum culling, thereby optimizing system rendering performance while ensuring the visualization of core business logic.

[0116] Furthermore, the digital twin fusion module supports automatic spatial positioning based on business events. When a specific device triggers a critical alarm, the digital twin fusion module receives a linkage instruction from the rules engine. In this embodiment, the system extracts the bounding box center coordinates of the target component and, combined with a preset observation offset angle, automatically generates a smooth 3D spatial roaming spline curve. The virtual camera moves along the 3D spatial roaming spline curve to the front of the target device, while simultaneously modifying the material shader of the target component locally to achieve highlighting, thus completing the rapid spatial positioning of the abnormal node.

[0117] In this embodiment, the platform constructs a SaaS application configuration layer. This layer serves as the front-end interface for the business model-driven engine, responsible for aggregating underlying atomic components, business rules, and digital twin scenarios, and generating the final building management application through visual operations.

[0118] In this embodiment, the SaaS application configuration layer incorporates a grid layout engine and a visual canvas. Developers drag and drop atomic components onto the visual canvas. The grid layout engine provides pixel-level snapping alignment. In practice, the system divides the visual canvas into a two-dimensional grid matrix of preset unit size. When a component is dragged onto the canvas, the engine intercepts the mouse release event, calculates the coordinates of the component's center point from the nearest grid intersection, and forcibly anchors the component to the grid intersection, thereby ensuring the standardization and consistency of the page layout.

[0119] After layout is complete, the platform performs parameter binding between components and underlying data. In this embodiment of the invention, the system provides a data mapping configuration panel. Developers select the input attributes of the target component through a drop-down menu and associate the input attributes with the standard interface fields exposed by the data model. The underlying layer adopts a two-way data binding mechanism. When the interface data changes, the component view on the front-end page is refreshed synchronously; when the end user inputs parameters in the component, the system writes the parameters back to the underlying database. Furthermore, after completing the interface layout and data binding, the platform serializes the visual configuration instructions on the canvas by the developers into standard structured text. The standard structured text is used to record the component call list, viewport coordinate positions, and data associations within the page.

[0120] During the no-code application development process, the platform's use of a general container nesting approach to accommodate various standardized components can easily lead to a deep Document Object Model (DOM) node tree during application generation. Simultaneously, multiple components concurrently requesting underlying data interfaces during page initialization can cause the front-end main thread to block, resulting in rendering stuttering on terminal devices. To ensure smooth application response, this embodiment introduces a page rendering complexity assessment mechanism in the SaaS application configuration layer. Before application deployment, the system parses the generated standard structured text and pre-calculates the estimated rendering time of the target page. The estimated rendering time is calculated as follows:

[0121] ;

[0122] In the formula, This represents the estimated rendering time of the target page, in milliseconds (ms). This represents the total number of visible components included in the page configuration list; Representing the The maximum depth of the document object model nodes nested within each component is a positive integer. The maximum node depth is pre-calculated and recorded in the metadata information table of the component library. This represents the rendering time constant per node. Those skilled in the art typically set the value of the constant based on the average processor performance of mainstream terminal devices. Under normal configuration, the value is 0.5 to 1.0 milliseconds per node. This represents the basic network latency of the interfaces required for page initialization. The system obtains the average response time of the current environment by sending network probe packets to the server, which is usually set between 50ms and 100ms. This represents the number of concurrent API requests triggered during the page initialization phase.

[0123] In this embodiment, when the calculated estimated rendering time When the smoothness threshold is exceeded (e.g., 1500ms), the system automatically intercepts the application deployment operation and outputs a performance overload warning to the configuration terminal. Simultaneously, the platform triggers an automatic downgrade rendering strategy. In practice, the system extracts viewport coordinates recorded in standard structured text and classifies components not located in the first visible area as low-priority components. The system adds a lazy-load flag to these low-priority components. During application runtime, the system parses the lazy-load flag and configures low-priority data tables or video components in skeleton screen placeholder mode, performing asynchronous rendering only after the core metrics and first-screen charts have finished loading.

[0124] Furthermore, the SaaS application configuration layer supports one-time configuration for multi-platform adaptation and deployment. Specifically, the system utilizes the elastic box model and Cascading Style Sheets (CSS) media query technology. The system dynamically adjusts the arrangement direction and scaling ratio of components based on the screen resolution and width of the terminal device. The deployment engine reads the standard structured text after performance evaluation and degradation processing, and automatically compiles and generates independent application installation packages suitable for personal computer web pages, mobile mini-programs, and industrial control panels, combined with the host frameworks of different operating environments.

[0125] In this embodiment, the platform deploys a multi-terminal application presentation layer on the user terminal. The multi-terminal application presentation layer is responsible for parsing the standard structured text sent from the cloud into the terminal operation interface and maintaining the real-time data link between the terminal device and the server.

[0126] In smart building management scenarios, device status changes and security alarms require millisecond-level real-time push notifications. In this embodiment, the application presentation layer calls the terminal's underlying network interface to establish a full-duplex communication link with the server. Specifically, the system prioritizes using the Network Sockets Protocol (NAT) for real-time communication. Due to the complexity of industrial sites or mobile network environments, full-duplex communication links often experience connection failures due to network fluctuations. To ensure continuous data transmission, the system incorporates an adaptive heartbeat protection mechanism.

[0127] In traditional communication mechanisms, the heartbeat packet transmission frequency is typically a fixed value. If the network environment deteriorates, a fixed-frequency heartbeat detection cannot detect link disconnection in a timely manner. In this embodiment of the invention, the system dynamically adjusts the heartbeat detection data packet transmission period based on real-time network quality indicators. The dynamic keep-alive period is calculated as follows:

[0128] ;

[0129] In the formula, This represents the dynamically calculated heartbeat keep-alive cycle, measured in milliseconds (ms). This represents the preset basic keep-alive period, which is typically set to between 30,000 ms and 60,000 ms by those skilled in the art. This represents the network round-trip latency in the most recent communication process, measured in milliseconds. The network round-trip latency is calculated by the underlying protocol stack sending system-level probe packets. This represents the delay attenuation coefficient, which typically ranges from 1.5 to 2.0. This represents the total number of communication data packets lost within a preset time window (e.g., 5 minutes). This represents the packet loss penalty coefficient, which is typically set to 500 milliseconds per packet in a normal network environment.

[0130] In this embodiment, when network latency increases or packet loss increases, the system automatically shortens the heartbeat keep-alive cycle. To improve the sensitivity of link status detection, and to prevent the calculated keep-alive period from being too small or even negative under extreme network conditions, causing system timer malfunctions, the system sets a minimum keep-alive period threshold, such as 5000ms. Furthermore, when the calculated keep-alive period... When the value is less than the minimum keep-alive period threshold, the system forces the detection to be performed according to the minimum keep-alive period threshold.

[0131] In practice, when the system detects that three consecutive heartbeat data packets have not received a response from the server, the terminal proactively releases the currently dead link and triggers an exponential backoff reconnection mechanism. This exponential backoff reconnection mechanism prevents the server from being overwhelmed by a massive number of connection requests during network recovery by gradually extending the retry interval. The calculation logic for the retry interval is as follows: the interval equals the base reconnection time (e.g., 2000ms) multiplied by 2. The system also sets a maximum number of retries (e.g., 10 times). Once the limit is reached, the system will display an offline error message on the interface and stop automatic reconnection.

[0132] On the other hand, in large-scale building operations, terminal applications often need to display historical alarm logs or device operation logs containing tens of thousands of records. Mounting all log nodes to the front-end document object model tree at once would overload the terminal device's memory. In this embodiment, a virtual long list rendering engine is introduced into the multi-terminal application presentation layer.

[0133] The virtual long list rendering engine employs the principle of dynamically mounting the visible area. In practice, the system monitors the scroll bar position on the terminal interface and calculates the data range to be displayed within the current screen viewport in real time. The system only renders data within the visible area as actual physical nodes; for data outside the visible area, it only retains the memory data structure without generating UI nodes. The total number of list elements actually participating in rendering within the current screen viewport is calculated as follows:

[0134] ;

[0135] In the formula, Represents the total number of list elements actually participating in rendering within the current viewport; This represents the absolute height of the visible area allocated to the list module on the current terminal screen, in pixels. The absolute height of the visible area is read in real time by the system through calling the terminal operating system's native view interface. Represents the fixed layout height of a single list item, in pixels; Represents the integer operation of rounding up; This represents the number of elements reserved in the pre-render buffer. These reserved elements are used to prevent a visual white screen when the end user scrolls through the list quickly. Those skilled in the art typically set the number of reserved elements to between 5 and 10.

[0136] Furthermore, this embodiment utilizes a cross-platform adapter interpreter built into the presentation layer. The cross-platform adapter interpreter reads the standard structured text generated by the front end. The system identifies the current terminal's host runtime environment and maps the common component tags defined in the standard structured text to the corresponding operating system's native UI controls in real time. For example, in a mobile operating system, the system maps the list component to a native scrolling view, while in a personal computer web browser, it maps it to standard Hypertext Markup Language elements, thus ensuring consistent performance of a single configuration code across multiple types of terminals.

[0137] This invention provides a zero-code intelligent building operation and maintenance system, which may include a processor, a memory, and a communication interface.

[0138] In this embodiment, the processor, memory, and communication interface are connected via an internal bus. The internal bus is used to enable data interaction between the various hardware components. Specifically, the internal bus includes an industry-standard architecture bus, a peripheral component interconnect standard bus, or an extended industry-standard architecture bus. The communication interface is used for data transmission with external devices or network nodes. In this embodiment, the processor is used to read and execute instruction code stored in the memory. In actual physical deployment, the processor includes a central processing unit, a graphics processing unit, a field-programmable gate array (FPGA), or an application-specific integrated circuit (ASIC).

[0139] In this embodiment, the memory is used to store software programs and module code. When the processor runs the software program stored in the memory, it executes the method operations provided by this invention. In specific implementation, when the processor executes instructions, it implements the steps described in the foregoing embodiments, such as atomized component resource aggregation and standardized interface access, logical flow of the visualization rule engine and system load assessment, digital twin model fusion and rendering weight calculation, SaaS application visualization configuration and rendering complexity assessment, and dynamic adjustment of multi-terminal application communication heartbeat and long list virtual rendering.

[0140] Embodiments of the present invention also provide a computer-readable storage medium. The computer-readable storage medium stores a computer program.

[0141] In this embodiment, when the processor reads and executes the computer program, it implements the method steps provided in any of the foregoing embodiments. Specifically, the computer program can drive the electronic device to execute the aforementioned building service management method, coordinate with the communication network to complete the fusion and interaction of multi-dimensional building service data and the three-dimensional building information model, and establish a real-time data link between the terminal device and the server.

[0142] Those skilled in the art will understand that computer-readable storage media include both non-volatile and volatile storage media. Common computer-readable storage media include read-only memory, random access memory, magnetic disks, optical disks, flash memory, and solid-state drives. The storage media listed above can tangibly store the instruction code and business data required to execute the technical solutions of this application, and exist independently of transiently propagating carrier signals, thus belonging to non-transient physical storage media.

[0143] Specific application example: Smart building project in a large commercial complex

[0144] Suppose a large commercial complex comprises a commercial podium and two super high-rise office buildings, with over 50,000 IoT monitoring nodes deployed (covering temperature and humidity, carbon dioxide levels, air conditioning units, security cameras, and fire smoke detectors). The management requires that, within one week, a comprehensive security and energy consumption monitoring application be built using the platform of this invention, with zero code.

[0145] Application configuration phase:

[0146] Developers accessed the SaaS application configuration layer, dragging and dropping components such as temperature and humidity monitoring and fresh air linkage control to create an interface. When configuring rules to trigger the fresh air system based on carbon dioxide concentration in the underground parking garage, the developers enabled a smoothing operator in the rule engine because the underlying sensors were susceptible to interference from instantaneous vehicle exhaust emissions, generating spike signals (causing frequent start-stop of the fresh air system). The system automatically calculates the valid signal output based on a formula:

[0147] ;

[0148] ;

[0149] With this configuration, the system can automatically filter out instantaneous high values ​​caused by exhaust gas, based on a stable effective concentration ( Dispatch the fresh air handling unit.

[0150] Runtime concurrent scheduling:

[0151] During peak summer electricity consumption, voltage fluctuations in a localized distribution cabinet triggered anomaly reports from over 2000 conventional devices (such as lighting offline), accompanied by a single real fire smoke alarm. At this point, the business model-driven engine initiated a queue-based dynamic scheduling mechanism. According to the formula: .

[0152] Due to the emergency level defined by fire smoke detectors ( The rate is relatively high, and there is no penalty for high-frequency retrying. Its scheduling priority score instantly jumped to the top. The platform prioritized the handling of fire alarms within 50ms and pushed the images to the large screen, preventing alarm storms from conventional equipment from blocking core business.

[0153] Digital twin 3D rendering:

[0154] When loading a super high-rise BIM model containing hundreds of thousands of components on the command screen, the digital twin fusion module dynamically calculates the rendering weight score of each component according to the formula: The system only supports views from close to the camera ( Smaller) and larger in volume ( Larger components, and components currently in an alarm state (service compensation). The components (=9) are assigned the highest precision polygon mesh rendering. The remaining distant areas and internal pipelines are automatically triggered by frustum culling, ensuring that the large screen image is maintained at a relatively smooth 60FPS.

[0155] Experimental verification and effect comparison:

[0156] To verify the actual operational effectiveness of the intelligent building operation and maintenance platform of this invention, two sets of core business comparison tests were conducted in a commercial complex project. The test results were obtained through... Figure 3 Line chart and Figure 4 The bar chart is used to display this information.

[0157] Verification of Sensor Signal Denoising and Smoothing Effect: Test Scenario: In an underground parking garage, due to instantaneous vehicle exhaust emissions or electromagnetic interference from equipment, carbon dioxide sensors are prone to reporting abnormally high concentration spikes. Test Method: Ten consecutive sampling periods were captured, and the original collected values ​​were compared with the values ​​processed by the system's smoothing.

[0158] Verification of Anomaly Detection Time in Weak Network Environments: Test Scenario: Mobile inspection terminals in buildings or IoT devices in basements are often in weak signal network environments. Test Method: Four network states (good network, slight fluctuation, network congestion, and extremely weak network) are set, and the heartbeat keep-alive detection time for determining device disconnection under different network states is compared between traditional platforms and the platform of this invention.

[0159] Anti-interference and stability analysis: Refer to Figure 3 The line graph showing the comparison of sensor data before and after smoothing processing demonstrates that the data smoothing mechanism of this invention can filter out instantaneous high-frequency noise. Figure 3 As shown, in the 3rd and 7th sampling periods, the original collected values ​​showed sudden increases of 850 and 900, respectively. After system smoothing, the corresponding output values ​​were suppressed to 415 and 435, filtering out short-term interference data, and the output curves matched the slow upward trend of the actual concentration. This processing method enables the system to filter out instantaneous interference from the physical environment, preventing related electromechanical equipment from malfunctioning due to sudden changes in sensor data, thereby reducing hardware wear and unnecessary energy consumption.

[0160] Network anomaly detection efficiency analysis: Reference Figure 4 The bar chart showing the comparison of device disconnection detection time under different network conditions demonstrates that the dynamic keep-alive mechanism of this invention possesses adaptive adjustment capabilities. Combined with... Figure 4 Traditional platforms use a fixed detection cycle, requiring 30 seconds to determine device offline under both good and extremely weak network conditions. The platform of this invention adjusts the detection cycle based on network quality, reducing the determination time to 22 seconds under slight network fluctuations and 12 seconds under network congestion; in extremely weak network environments, the offline determination time is reduced from 30 seconds to 5 seconds. Compared to the fixed-cycle detection method, the dynamic keep-alive mechanism shortens the device offline determination time, meeting the real-time requirements of building security alarms and equipment scheduling.

Claims

1. A zero-code intelligent building operation and maintenance platform, characterized in that: include: The IaaS infrastructure layer provides computing resources, data persistence media, and network communication links. The PaaS engine and component layer, deployed on top of the IaaS infrastructure layer, includes a business model-driven engine, a three-layer atomic component library, a visualization rule engine, and a digital twin fusion module. These are used to perform business model parsing, cross-system linkage logic processing, provide modular resources, and perform 3D scene fusion of building information models and business models. The SaaS application configuration layer is used to receive input visual configuration instructions and serialize the visual configuration instructions into standard structured text; The multi-terminal application presentation layer is used to parse the standard structured text into a terminal operation interface, establish a real-time data link with the server, and output business functions.

2. The zero-code intelligent building operation and maintenance platform according to claim 1, characterized in that, The business model driving engine has a built-in queue-based dynamic scheduling mechanism to handle concurrent events; The dynamic scheduling mechanism determines the task execution order by calculating the scheduling priority score of the service request; The scheduling priority score is calculated as follows: Multiply the predefined event urgency level by its corresponding level weight, add the product of the waiting time accumulated in the system queue for the business request and its corresponding time weight, and subtract the degradation penalty factor caused by high-frequency retries. The downgrade penalty factor is determined based on the number of times the same anomaly is reported consecutively within a preset time window.

3. The zero-code intelligent building operation and maintenance platform according to claim 1, characterized in that, The visualization rule engine evaluates the execution cost of the rule instances to be processed, calculates the cost evaluation value, and distributes the rule instances to the corresponding execution queues. The rule instance is transformed from the business rule tree parsed by the visualization rule engine. The calculation method for the computational cost evaluation value of a single rule instance is as follows: Multiply the total number of logical nodes in the business rule tree by the parsing step size constant of a single node, and add the sum of the average response latency costs corresponding to each external data call interface; The visualization rule engine allocates the rule instance to the fast execution queue or the asynchronous execution queue based on the magnitude of the computational overhead evaluation value.

4. The zero-code intelligent building operation and maintenance platform according to claim 1, characterized in that, The digital twin fusion module includes a dynamic level-of-detail scheduling mechanism based on viewpoint distance; The dynamic detail level scheduling mechanism controls rendering accuracy by calculating the rendering weight score of target components in the 3D scene in real time. The calculation method for the rendering weight score is as follows: Divide the volume of the target component's spatial axial bounding box by the square of the straight-line spatial distance from the virtual camera's focus to the target component's center point, multiply by the screen resolution calibration factor, and add the service enhancement compensation value used to ensure the rendering of alarm status components. The digital twin fusion module assigns high-precision mesh models, low-polygon mesh models, or performs view frustum culling to the components in the scene based on the rendering weight score.

5. The zero-code intelligent building operation and maintenance platform according to claim 1, characterized in that, The visual configuration instructions are used to configure the target page to be published. The SaaS application configuration layer pre-calculates the estimated rendering time of the target page before the application is published. The estimated rendering time is calculated as follows: Calculate the sum of the products of the maximum depth of the document object model nodes nested within each visible component in the target page configuration list and the single node rendering time constant, and add the product of the basic network latency of the interface to be called for the initialization of the target page and the number of concurrent interface requests. When the estimated rendering time exceeds the preset smoothness threshold, the SaaS application configuration layer intercepts the application release operation, determines the components that are not in the first visible area of ​​the target page as low-priority components, and adds a lazy loading flag to the low-priority components.

6. The zero-code intelligent building operation and maintenance platform according to claim 1, characterized in that, The three-layer atomic component library performs a memory overhead assessment on the target page before dynamically loading resources; The calculation method for dynamically loaded memory evaluation values ​​is as follows: Sum the products of the static resource file sizes of each component referenced by the page and the rendering memory expansion coefficient, and add the product of the deepest level of the dependency chain between nested components within the page and the chain resolution overhead constant. When the dynamically loaded memory evaluation value exceeds the preset memory limit threshold, an asynchronous lazy loading mechanism is triggered to delay the loading of components in areas not visible on the first screen of the target page.

7. The zero-code intelligent building operation and maintenance platform according to claim 1, characterized in that, The multi-terminal application presentation layer uses the Network Sockets Protocol to establish a full-duplex communication link and has a built-in adaptive heartbeat keep-alive mechanism. The adaptive heartbeat keep-alive mechanism dynamically adjusts the sending period of heartbeat probe data packets based on real-time network quality indicators, i.e., the dynamic keep-alive period. The dynamic keep-alive period is equal to the preset basic keep-alive period, minus the product of the network round-trip delay time and the delay attenuation coefficient, and then minus the product of the total number of lost communication data packets and the packet loss penalty coefficient. When the dynamic keep-alive period is less than the set minimum keep-alive period threshold, the detection is forced to be performed according to the minimum keep-alive period threshold.

8. The zero-code intelligent building operation and maintenance platform according to claim 1, characterized in that, The multi-terminal application rendering layer includes a virtual long list rendering engine; The virtual long list rendering engine calculates in real time the total number of list elements actually participating in rendering within the current screen viewport; The total number of list elements is obtained by dividing the absolute height of the visible area by the fixed layout height of a single list data item, rounding up, and then adding the number of elements reserved in the pre-rendering buffer. The virtual long list rendering engine generates interface nodes for list elements within the viewport, while preserving the memory data structure for data in non-visible areas without generating interface nodes.

9. A zero-code intelligent building operation and maintenance system, characterized in that: include: Communication interface, memory, and processor; The memory is used to store computer programs; when the processor reads and executes the computer programs, it realizes the functional interaction and logical flow of the zero-code smart building operation and maintenance platform according to any one of claims 1 to 8.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, which, when read and executed by a processor, realizes the functional interaction and logical flow of the zero-code smart building operation and maintenance platform as described in any one of claims 1 to 8.

Images