Intelligent community management system based on cloud service

Abstract

The invention relates to the technical field of community management, and discloses an intelligent community management system based on cloud service. The system comprises a community basic data management module, a building structure information module, a public equipment monitoring module, a cloud data interaction module and a user authority management module. The community basic data management module maintains community static information and dynamic records; the building structure information module stores building physical attribute data and resident association information; the public equipment monitoring module collects real-time operation state data and historical performance indexes of public equipment; the cloud data interaction module realizes local and cloud data transmission synchronization; and the user permission management module allocates operation permissions according to preset role types. The system realizes data integration, equipment monitoring, authority specification and cloud interaction in a community management process through multi-module cooperation, and is suitable for efficient operation of a community management background.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of community management, in particular to a smart community management system based on cloud services. BACKGROUND

[0002] At the data management level, community basic information is often scattered in multiple independent record carriers. Static information such as community geographical area division and public facility distribution exists in the form of paper archives or single electronic table, while dynamic records such as resident registration and vehicle access are stored in different management software. There is a lack of effective association between static and dynamic information. If a manager needs to query the use of community public facilities corresponding to a resident, he needs to switch repeatedly among multiple systems or archives, which is tedious and prone to information omission.

[0003] In terms of building management, the physical property data and resident information of a building are usually maintained by different personnel. For example, physical parameters such as building number and unit quantity may be recorded by the engineering department, while resident list and property status information may be managed by the property front desk. Both are stored in independent databases. When it is necessary to count the house type corresponding to the residents of a unit, it is necessary to manually check two sets of data, which not only consumes time but also may result in deviation due to asynchronous data update.

[0004] In the field of public equipment monitoring, the traditional method relies on independent monitoring devices of single equipment or manual inspection to record equipment status. Real-time data such as running power and temperature of public facilities such as elevators and water supply equipment are difficult to collect centrally. When a device fails, the alarm signal is usually displayed only at the local device end, and the manager is difficult to notice in time. At the same time, historical data such as monthly energy consumption and maintenance records of the equipment are scattered in maintenance logs or paper reports, which are difficult to systematize and cannot form a complete understanding of the long-term running status of the equipment.

[0005] In terms of data storage and interaction, most community management systems rely on local servers, and data storage is limited by hardware capacity and is prone to data loss due to server failure. In a community with cross-regional management, the management systems of different partitions are independent, and data cannot be synchronized in real time. If the headquarters manager needs to grasp the running status of each partition, he needs to manually aggregate data through email, USB and other means, which is not only inefficient but also may result in data tampering or omission during transmission.

[0006] In terms of permission management, the traditional system divides the operation permissions in a rough way, often only simply distinguishing between administrators and ordinary users, without considering the differentiated needs of intermediate roles such as property execution personnel and building responsible person. In some scenarios, the building responsible person may need to view the equipment running data of the building but has no corresponding permission, while the ordinary resident may misoperate the functions beyond his duties, resulting in chaotic system operation and affecting the management order. SUMMARY

[0007] The present application aims to provide a cloud service-based smart community management system to solve the problems raised in the background art.

[0008] To achieve the above-mentioned purpose, the present application provides a cloud service-based smart community management system, which comprises:

[0009] A community basic data management module for maintaining static information and dynamic records required for the overall operation of the community, wherein the static information includes community geographical area division, public facility distribution and property management architecture information, and the dynamic records include resident registration data, vehicle access records and service request processing results;

[0010] A building structure information module for storing physical property data and resident associated information of each building, wherein the physical property data includes building number, unit quantity, floor height and house type distribution parameters, and the resident associated information includes unit resident list, house property rights status and resident family member information;

[0011] A public equipment monitoring module for collecting real-time operation state data and historical performance indicators of community public equipment, wherein the real-time operation state data includes equipment operation power, temperature parameters and fault alarm signals, and the historical performance indicators include monthly energy consumption statistics, fault occurrence frequency and maintenance records;

[0012] A cloud data interaction module for realizing data transmission and synchronization between the local management system and the cloud server;

[0013] A user permission management module for assigning system operation permissions according to preset role types, wherein the preset role types include system administrator, property executive, building responsible person and ordinary resident, and the operation permissions include data viewing range, function use permission and approval process configuration permission.

[0014] Preferably, the community basic data management module comprises:

[0015] An information classification unit for dividing community data into property input data, resident submitted data and system automatically collected data according to data producing subjects;

[0016] A record updating unit for starting an information updating process when receiving a data change instruction, replacing historical records after verifying the validity of new data through data verification rules;

[0017] A version control unit for generating version identification for each data update, recording update time, operation user and change content, and forming a traceable version history log.

[0018] Preferably, the building structure information module comprises:

[0019] a structure editing unit configured to provide a visual editing interface of building physical attributes, and support adding building records, modifying unit configurations, and deleting obsolete building information;

[0020] a resident association unit configured to establish a binding relationship between house numbers and resident identity information, and support a many-to-many relationship configuration of a single resident associated with multiple houses and a single house associated with multiple residents;

[0021] a state marking unit configured to dynamically update house state labels according to house occupancy, including empty, self-occupied, rented, and for-sale states, and synchronously update the community data overview panel.

[0022] Preferably, the record updating unit comprises:

[0023] a change detection subunit configured to monitor community data storage directories in real time, and trigger a change notification when detecting file modification, addition, or deletion operations;

[0024] a data verification subunit configured to perform format verification, logic verification, and integrity verification on changed data, wherein the format verification verifies whether data fields meet preset data type requirements, the logic verification verifies whether associated data is contradictory, and the integrity verification verifies whether required fields are missing;

[0025] a conflict resolution subunit configured to, when local data and cloud synchronization data conflict, select a data version to retain according to preset priority rules, wherein the priority rules include a time stamp latest priority, a data source credibility priority, and a manual review confirmation priority.

[0026] Preferably, the version control unit comprises:

[0027] a version generation subunit configured to generate a unique version identifier using a combination of a time stamp and a random sequence, to ensure that version numbers of different update operations are not repeated;

[0028] a log recording subunit configured to write key information of each version update into an audit log, including an operation user ID, data snapshots before and after the update, and an operation IP address;

[0029] a rollback recovery subunit configured to support restoring data to a historical state according to a version identifier or a time point, and automatically creating a backup version of the current state during the recovery process.

[0030] Preferably, the system further comprises:

[0031] a data backup module configured to configure an automatic backup strategy for community data, including backup frequency, backup medium, and backup retention period;

[0032] The backup execution module is configured to periodically start a data backup task according to a backup strategy, and perform full backup or incremental backup on community basic data, building information and device monitoring data.

[0033] The backup verification module is configured to perform integrity verification and availability test on the generated backup file, so as to ensure that the backup data can be normally restored, wherein the integrity verification is achieved by checksum comparison, and the availability test is achieved by simulating a recovery process.

[0034] Preferably, the public device monitoring module comprises:

[0035] The device classification unit is configured to divide the community public devices into power devices, water supply and drainage devices, security devices and environmental monitoring devices according to the function types of the devices.

[0036] The parameter acquisition unit is configured to acquire device operation parameters in real time through an Internet of Things interface, including voltage value, current value, flow value, pressure value and temperature and humidity value.

[0037] The abnormality identification unit is configured to compare the acquired real-time parameters with a preset normal range, and generate an abnormal event when the parameters exceed the normal range, wherein the abnormal event comprises parameter out-of-limit alarm, device offline alarm and state mutation alarm.

[0038] Preferably, the abnormality identification unit comprises:

[0039] The threshold configuration subunit is configured to configure independent normal range thresholds for each operation parameter of different types of devices, and support two configuration modes of static threshold and dynamic threshold, wherein the dynamic threshold is automatically adjusted according to historical data statistical analysis.

[0040] The real-time comparison subunit is configured to compare the real-time acquired parameter values with the current effective threshold point by point, calculate the parameter deviation percentage and record the continuous abnormal duration.

[0041] The event generation subunit is configured to generate an abnormal event work order containing device identification, abnormal parameter, occurrence time and suggested treatment measures when the parameter deviation percentage exceeds the deviation threshold or the continuous abnormal duration reaches the duration threshold.

[0042] Preferably, the user permission management module comprises:

[0043] The role definition unit is configured to create system operation roles and configure role permission sets, wherein the permission sets comprise menu access permission, button operation permission, data query permission and report export permission.

[0044] A user allocation unit is configured to associate a system user account with one or more roles, implement role-based permission control, and support a user having the combined permissions of multiple roles.

[0045] A permission audit unit is configured to periodically audit the allocation of user permissions, check whether there is over-allocation of permissions, long-term non-use of permissions, or mismatch between permissions and job responsibilities.

[0046] Preferably, the system further comprises:

[0047] A service process management module is configured to process various service requests initiated by community residents, wherein the service requests include maintenance applications, complaints and suggestions, repair of articles, and reservation of sites; and the service process management module comprises:

[0048] A request classification subunit is configured to automatically classify the type of a service request according to the content features of the service request, wherein the classification is based on the emergency degree of the service, the type of the facility involved, and the department to which the processing department belongs.

[0049] An intelligent order allocation subunit is configured to automatically allocate a service request to an optimal processing personnel based on the current load, skill matching degree, and geographic location information of the processing personnel.

[0050] An abnormality processing subunit is configured to trigger an early warning mechanism and automatically upgrade to a superior processing node when the processing of a service request is overdue or abnormal, wherein the early warning mechanism includes system message reminders, SMS notifications, and priority improvement of the work order.

[0051] Compared with the prior art, the present application has the following advantages:

[0052] The community basic data management module integrates static information such as community geographic area division and public facility distribution into the same management framework with dynamic records such as resident registration and vehicle access, so that originally dispersed information can be presented in a centralized manner. When a manager needs to understand the correlation between the use of community public facilities and the flow of residents within a certain time period, the manager does not need to switch between multiple systems, but can directly obtain the integrated information in the module, making the relevant data of community overall operation more coherent.

[0053] The building structure information module associates the physical property data of a building with the resident information of the building, so that physical parameters such as building number and unit quantity and information such as unit resident list and property status form a whole that echoes each other. When it is necessary to understand the matching condition of the layout of a building and the composition of the family members of the residents, the module can be directly used to realize the linkage query of information, avoiding the query obstacles caused by the separation of physical data and resident information in traditional management, and making the connection of information for building management more natural.

[0054] The public equipment monitoring module simultaneously collects real-time operating status data and historical performance indicators of the equipment. Real-time data such as equipment operating power and temperature, along with historical data such as monthly energy consumption and fault frequency, together constitute a complete description of the equipment's status. When managers view the current operating status of a particular piece of equipment, they can simultaneously understand its past energy consumption changes and fault patterns, forming a comprehensive understanding of the equipment's operating status and providing a more three-dimensional perspective on equipment management.

[0055] The cloud-based data interaction module breaks down the geographical limitations of local management systems, enabling data transmission and synchronization between local and cloud servers. For communities with cross-regional layouts, management data from each zone can be uploaded to the cloud in real time. Headquarters managers can obtain consistent data from each zone through the cloud without relying on manual aggregation, allowing management information from different regions to flow smoothly and making cross-regional information transmission more efficient.

[0056] The user access control module assigns operation permissions according to preset role types, clearly defining the scope of operation and functional boundaries for different roles such as system administrators and property management personnel. Property management personnel can handle service requests within their authorized scope, building managers can only view relevant data for their own building, and ordinary residents' operations are limited to a reasonable range. Different roles operate according to their own rules within the system, avoiding confusion caused by overlapping or missing permissions and making the system operation more orderly.

[0057] The modules do not operate in isolation, but rather cooperate to form an organic whole. The linkage between basic community data and building information makes the connection between resident information and the overall community environment closer; public equipment monitoring data is shared through cloud interaction modules, allowing equipment status information to be accessed as needed by roles with different permissions; and access control provides a standardized operational framework for the information flow between modules. This multi-module collaboration ensures that information transmission, equipment supervision, and access control in the community management process are interconnected, forming a coherent management workflow. Attached Figure Description

[0058] Figure 1 This is a schematic diagram illustrating the working principle of the cloud-based smart community management system described in this invention.

[0059] Figure 2 A flowchart illustrating the operation of the building structure information module;

[0060] Figure 3 A flowchart illustrating how the version control unit works;

[0061] Figure 4 A flowchart illustrating the operation of the anomaly detection unit. Detailed Implementation

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

[0063] Please see Figure 1 This invention provides a cloud-based smart community management system. The system includes: a community basic data management module, a building structure information module, a public equipment monitoring module, a cloud data interaction module, and a user access control module. These modules work collaboratively to achieve full-process digital management of the community. Specific implementation steps are as follows:

[0064] The community basic data management module is responsible for maintaining the static information and dynamic records required for community operation. Static information includes the community's geographical division, such as marking community boundaries and internal functional zones using electronic maps; the distribution of public facilities, including the location information of fitness equipment, children's playgrounds, and garbage transfer stations; and property management structure information, recording the property management department's setup, staffing, and division of responsibilities. Regarding dynamic records, resident registration data includes identity information, move-in time, and lease agreement; vehicle entry and exit records are collected through the access control system, collecting license plate information, entry and exit times, and access permissions; and service request processing results are recorded in detail, including resident requests, processing procedures, and feedback.

[0065] The building structure information module stores the building's physical attribute data and resident association information. In the physical attribute data, building numbers are formatted as "area code-building serial number," the number of units is recorded according to the actual building structure, floor height includes both above-ground and underground floors, and the unit distribution parameters indicate the number and area of ​​different unit types on each floor. In the resident association information, the unit resident list is sorted by door number, the property ownership status is distinguished between private ownership, shared ownership, and collective ownership, and resident family member information records names, relationships, and contact information.

[0066] The public equipment monitoring module collects real-time operating status data and historical performance indicators of public equipment. Real-time operating status data is obtained through sensors, including equipment operating power, key component temperatures, and fault alarm signals. An alarm is triggered immediately when equipment malfunctions. Historical performance indicators include monthly energy consumption statistics (summarizing electricity and water consumption by equipment type), fault frequency statistics (counting the number of faults within a specific period), and maintenance records detailing maintenance time, content, and the person responsible for each maintenance.

[0067] The cloud data interaction module builds a communication bridge between the local system and the cloud server, and uses an encrypted transmission protocol to achieve bidirectional data transmission, ensuring real-time synchronization between local and cloud data. When the network is interrupted and then restored, the breakpoint resume mechanism is automatically started to ensure data integrity.

[0068] The user access control module assigns operation permissions based on preset role types. System administrators have full-function operation permissions, property management staff can handle daily service requests and equipment monitoring, building managers can only view data for their assigned buildings, and ordinary residents can only access their own information and submit service requests. The data viewing scope, function usage permissions, and approval process configuration permissions are clearly distinguished for different roles.

[0069] Example 1: See Figure 2 The community basic data management module and the building structure information module work together to achieve refined management of community data and dynamic maintenance of building information.

[0070] The community basic data management module categorizes community data according to the data generating entity. Property management data includes various information generated during property management, such as regular inspection records of public facilities (including inspector names, inspection times, and facility operation status); detailed property fee standards (including unit prices for different apartment types, payment cycles, and preferential policies); and property staff schedules (recording work hours and shift arrangements for each position). Resident-submitted data includes information proactively provided by residents during move-in and residency, such as employment and health status of family members filled in during move-in applications; renovation plans, construction times, and construction personnel information submitted during renovation registration; and requests for neighborhood dispute mediation and community activity participation registration submitted through the community app. System-automated data is automatically acquired by the system through various sensors or interfaces, such as license plate information, entry / exit times, and parking duration generated from vehicle entry / exit images captured by parking lot entrance cameras; water and electricity consumption records from smart water and electricity meters; and automatically generated elevator operation records (number of trips and floors visited). These data are stored in separate tables according to their categories. Each table's fields are customized based on the data type, and a category identifier field is added to each data record to quickly distinguish the data source type.

[0071] The record update unit initiates a complete update process upon data change. Data change commands can be triggered in various ways: property management staff can manually modify data by filling out forms in the system backend, such as updating maintenance records for public facilities; residents can submit data change requests through the community portal or app, such as changing contact numbers or emergency contacts; the system automatically triggers change commands under specific conditions, such as automatically marking a vehicle as "long-term unused" if it hasn't entered or left the community for three consecutive months. Upon receiving a change command, the system calls preset data verification rules to verify the new data. Verification rules are customized based on data type; for example, when verifying a resident's submitted ID number, it checks if the number is 18 digits long and if the last check digit conforms to the algorithm rules; when verifying vehicle information, it checks if the license plate color matches the vehicle type, such as a blue license plate corresponding to a small vehicle; when verifying renovation construction time, it checks if it falls within the community's designated construction period. After successful verification, the system overwrites the historical records with new data and marks the old records as "invalid" in the database; if the verification fails, the system returns specific error messages, such as "ID number format is incorrect, please re-enter" or "Construction time exceeds the allowed range, weekday construction time is 9:00-18:00", and guides the user to make corrections.

[0072] The version control unit generates a unique version identifier for each data update. This identifier uses the format "year, month, day, hour, minute, second + 4 random digits," such as "202405201430251234," ensuring that even if multiple updates occur within the same second, the version identifier will not be duplicated. Simultaneously, the system records the update time in detail, accurate to milliseconds; it also records the account name of the user performing the operation (for data submitted by residents, the resident's ID number or resident ID number); and it records the changes in detail, using the format "field name: old value → new value," such as "contact number: 13800138000 → 13900139000" or "property status: owner-occupied → rented." This information is compiled into a version history log, stored chronologically in a dedicated log table. The log can be queried by data ID, update time range, user, and other criteria, and the query results display the complete version change trajectory.

[0073] The building structure information module's structure editing unit provides an intuitive visual editing interface. The left side of the interface displays a tree-structured list of community buildings, while the right side is a detailed information editing area for the selected building. It graphically displays the building's exterior diagram and floor distribution. To add a new building record, users click the "Add" button, fill in the building number, construction year, number of units, number of households per floor, and upload the building floor plan. The system automatically generates the building's basic record and adds it to the tree structure. To modify unit configurations, users can select a building's unit list, adjust the number of units, modify unit numbering rules, and set the number and location of elevators for each unit. After editing, clicking the "Save" button updates the building's unit information in real time. When deleting information about abandoned buildings, the user selects the building to be deleted, and the system pops up a confirmation window displaying the basic information of the building and the number of associated residents. After the user confirms, they enter the reason for deletion, such as "Building has been demolished" or "Record error requires deletion". The system then performs the deletion operation, marks all information of the building as "deleted", and retains a 30-day deletion buffer period in the background. During this period, the data can be restored with administrator privileges. After the buffer period, the data is completely cleared.

[0074] The resident association system establishes a binding relationship between house numbers and resident identity information, supporting many-to-many relationship configurations. When a single resident owns multiple houses, such as purchasing two apartments within the community, the system associates the resident's identity information with two different house numbers in the database, recording the purchase time and usage purpose (e.g., owner-occupied, rented) for each house. When a single house is associated with multiple residents, such as a house shared by a couple and their children, the system associates the house number with multiple resident identity information, marking each resident's relationship to the house (e.g., owner, spouse, children), move-in time, and whether they are the primary contact person. Establishing the association requires identity verification; residents must provide proof of identity such as their ID card, property certificate, or lease agreement, which must be reviewed and approved by property management staff before the system is activated. When the association changes, such as when a resident sells a house or changes a roommate, a change application must be submitted. After review, the system records are updated, and a change log is generated, recording the association information before and after the change, the operation time, and the reviewing personnel.

[0075] The status label unit dynamically updates the status tags based on the actual occupancy status of the properties. The system periodically (e.g., every morning) scans all property occupancy registration data, lease agreement information, and water and electricity usage records to comprehensively determine the property status: properties with no occupancy registration for six consecutive months and zero water and electricity usage are marked as "Vacant"; properties where the occupant registration information shows the property owner and water and electricity usage is regular are marked as "Occupied"; properties with signed lease agreements and registered tenant information are marked as "Rented"; and properties registered with a real estate agency and where the property owner has submitted a sale application are marked as "For Sale". After the status tags are updated, the system immediately synchronizes them to the community data overview panel. The overview panel uses different colors to distinguish different statuses, such as red for "For Sale", green for "Occupied", yellow for "Rented", and gray for "Vacant". It also displays the number and percentage of properties in each status by building, presented in bar charts, pie charts, etc., allowing property management personnel to quickly understand the overall usage of the community's properties.

[0076] Example 2: See Figure 3 The record update unit and version control unit achieve accurate updates and full lifecycle management of community data through a multi-layered data processing mechanism.

[0077] The record update unit comprises a change detection subunit, a data verification subunit, and a conflict resolution subunit, all working collaboratively to complete the data update process. The change detection subunit employs a dual monitoring mechanism to monitor the community data storage directory in real time. Firstly, a timed scanning program performs an integrity check on files in the data directory every 30 seconds, comparing file modification times and size changes. Secondly, through the system's underlying event listening interface, a change notification is immediately triggered when a file is opened, modified, saved, or deleted. The change notification includes the operation type (e.g., add, modify, delete), a unique identifier for the data involved (e.g., resident ID, device number), the precise time the operation occurred, and the terminal device information that performed the operation. This notification information is pushed to the data processing center in real time via an internal message queue, ensuring that data changes are captured promptly.

[0078] The data validation subunit performs a triple validation process on changed data. The format validation step sets validation rules for different data fields. For example, date fields must conform to the "YYYY-MM-DD" format, mobile phone numbers must be 11 digits starting with 1, and house area fields must be positive numbers with two decimal places. The logic validation step ensures consistency through comparison of related data. For example, when validating a resident's move-in date, it must be confirmed that the date is later than the house delivery date but earlier than the current date; when validating vehicle access permissions, it must be verified that the resident ID in the vehicle registration information matches the resident ID in the permission record; when validating equipment maintenance records, it must be confirmed that the maintenance time is after the equipment installation time. The integrity validation step checks for missing required fields. For example, name, ID number, and contact number are required in resident registration data, and equipment number, type, and installation location are required in equipment information. Missing any of these fields results in validation failure. Data that fails validation is temporarily stored in the abnormal data pool, and a detailed error report is generated, indicating the erroneous fields and reasons. The data submitter or administrator must then correct the errors and resubmit for validation.

[0079] When inconsistencies arise during the synchronization of local and cloud data, the conflict resolution subunit handles them according to preset priority rules. When the latest timestamp priority rule is enabled, the system extracts the last updated timestamps of both local and cloud data, accurate to milliseconds, automatically retains the updated version, and archives the replaced version to the historical database. When the data source credibility priority rule is enabled, the system judges data according to preset source credibility levels (e.g., system-automatically collected data > property management-approved data > resident-submitted data). For example, if a resident changes their local phone number, while the same resident's phone number is entered by property management staff on the cloud, the system retains the cloud data. When the manual review and confirmation priority rule is enabled, the system displays the conflicting data in a comparison table on the review interface, marking the differences and source information. Reviewers can choose to retain the local version, the cloud version, or manually enter new values. The review results must record the reviewer's ID and review comments as a basis for future traceability.

[0080] The version control unit comprises a version generation subunit, a log recording subunit, and a rollback and recovery subunit. The version generation subunit uses a composite encoding rule to generate a version identifier, consisting of 17 characters. The first 13 characters are a timestamp (accurate to milliseconds, e.g., 202405201530251 represents May 20, 2024, 15:30:25.1), and the last 4 characters are a random alphanumeric combination to ensure the uniqueness of the version identifier in high-concurrency scenarios. The version identifier is associated with the corresponding data record via a foreign key and stored in a version mapping table, facilitating quick retrieval of all historical versions of a given data entry.

[0081] The log recording sub-unit meticulously records key information for each version update, forming an immutable audit log. Log entries include the operation user ID, which is associated with the system user table and allows querying the user's name, department, and position. Data snapshots before and after the update are stored in JSON format, fully preserving the old and new values ​​of all fields. For long text or binary data, reference addresses are used to point to the storage file. The operation IP address is obtained through the system network interface, recording the network address of the terminal device performing the operation for easy identification of the operation's origin. Audit logs are stored in blocks according to time sequence, with one log file generated every hour. Querying is supported by multiple conditions, including version identifier, operation user, data type, and time range, and log export functionality is also provided.

[0082] The rollback and recovery subunit supports historical version recovery of data. Users can initiate a recovery request in two ways: first, by selecting a version identifier from the historical version list on the data details page and clicking the "Restore this version" button; second, by entering a specified time point on the data recovery interface, and the system automatically finds the latest version corresponding to that time point. After the recovery process starts, the system first performs a complete backup of the current data state, generates a new version identifier and records it to the version log, and then overwrites the current data with the selected historical version data. After the recovery is complete, the system generates a recovery report, including the restored version identifier, a comparison of the data before and after the recovery, the operation time and the user who performed the operation, and notifies the relevant personnel via system message. If data anomalies are found after recovery, a quick rollback can be performed using the latest backup version to ensure the reversibility of data operations.

[0083] Example 3: The system ensures data security through a data backup module, a backup execution module, and a backup verification module, while the public equipment monitoring module enables comprehensive monitoring of community equipment.

[0084] The data backup module is used to configure automatic backup strategies for community data. Users can adjust backup parameters in the system settings interface. Backup frequency options include 2 AM daily, 3 AM every Sunday, or 4 AM on the last day of each month. After selection, the system will automatically execute backup tasks at the set time. Backup media can be selected from local storage (such as the server's internal hard drive), external storage devices (such as portable hard drives and USB flash drives), and cloud storage space (such as Alibaba Cloud and Tencent Cloud storage buckets). Multiple media can be configured simultaneously for redundant backups. Backup retention periods are set differently based on data types. Basic community data (such as building structure and property information) can be set to be retained for 365 days, daily operation records (such as service request processing logs) can be set to be retained for 90 days, and temporary data (such as temporary visitor records) can be set to be retained for 30 days. The strategy configuration interface provides save and reset functions. After each modification, the system automatically records the modification time, the modifier, and the changed content, forming a strategy change history for easy tracking of the adjustment process.

[0085] The backup execution module initiates backup tasks according to a preset backup strategy. During a full backup, the system completely copies the geographical area divisions and public facility distributions from the community's basic data, the physical attributes and resident association data from building information, and the real-time status and historical indicators from equipment monitoring data, generating a backup file containing all data. The file name format is "Full Backup_YYYYMMDD_HHMMSS". During incremental backups, the system compares the database logs since the last backup and only backs up data that has been added, modified, or deleted. The generated incremental backup file name format is "Incremental Backup_YYYYMMDD_HHMMSS_Relative to [Last Backup Time]". Before starting a backup task, the system automatically checks the available space on the target storage medium. When space is insufficient (e.g., available space is less than 1.2 times the estimated backup file size), a space warning message is sent to the administrator, and the backup task is paused. After the administrator clears the space or replaces the storage medium, the system automatically restarts any unfinished backup tasks, ensuring the backup process is uninterrupted.

[0086] The backup verification module performs dual verification on the generated backup files. Integrity verification is achieved by calculating the MD5 checksum of the backup files. The system calculates the checksum for both the original data file and the backup file; if they match, the backup is considered complete; otherwise, it is marked as corrupted. Availability testing is conducted by simulating a recovery process. The system restores the backup files to an independent test database environment, checking the integrity of the data table structure and the consistency of the number of records with the backup. Simultaneously, basic query operations (such as querying a list of residents in a building or historical operating data of a device) are performed to verify that the data can be read and used normally. After verification, the system generates a verification report, including the backup file name, verification time, integrity result, availability result, and anomaly details (e.g., specifying the file name and location of corrupted files). If verification fails, the system automatically triggers a re-backup mechanism, overwriting the unqualified backup files and recording the number of retries. If the backup fails after more than three retries, an emergency alert is sent to the administrator.

[0087] The public equipment monitoring module categorizes community public equipment based on its function. Electrical equipment includes transformers, high-voltage distribution boxes, low-voltage distribution boxes, charging piles, and public lighting control boxes, each marked with a unique electrical equipment code. Water supply and drainage equipment includes domestic water pumps, fire pumps, water storage tanks, sewage treatment equipment, water supply pipe valves, and drainage pipe sensors, grouped by building or area. Security equipment includes high-definition surveillance cameras, facial recognition access control machines, infrared beam alarms, electronic patrol points, and fire alarm controllers, linked to the community security system. Environmental monitoring equipment includes temperature and humidity sensors, noise monitors, PM2.5 detectors, light sensors, and rain sensors, distributed in community public areas and green belts. Each type of equipment corresponds to an independent database table, storing its basic information (such as model, installation date, and manufacturer) and associated monitoring parameters.

[0088] The parameter acquisition unit acquires equipment operating data in real time via an IoT interface. Smart meters and current transformers connected to power equipment collect voltage (V), current (A), active power (kW), and power factor; flow meters in water supply and drainage equipment collect flow rate (m³ / h), pressure sensors collect pipeline pressure (MPa), and level gauges collect water level in reservoirs (m); security equipment transmits online status (online / offline), signal strength (percentage), and trigger records (such as access control opening time and alarm trigger time) via network interfaces; sensors in environmental monitoring equipment collect air temperature (°C), relative humidity (%), noise level (dB), and PM2.5 concentration (μg / m³). The acquisition frequency is set according to the importance of the equipment: critical equipment such as transformers and fire pumps collect data every 10 seconds, while ordinary equipment such as public lighting and temperature / humidity sensors collect data every 60 seconds. The collected parameter values ​​are transmitted in real time to the local data cache and simultaneously synchronized to the cloud database to ensure no data loss.

[0089] The anomaly identification unit identifies abnormal equipment states through parameter comparison. Parameter exceeding limits alarms indicate that equipment operating parameters exceed normal ranges, such as transformer temperature exceeding 80℃ or water supply pipeline pressure falling below 0.2MPa. Equipment offline alarms indicate that communication between the equipment and the monitoring system is interrupted for more than 10 minutes (the duration threshold can be manually adjusted), such as a surveillance camera losing network connectivity. Sudden state change alarms indicate that parameters change drastically within a short period, such as a current value increasing by more than 50% within one minute or a sudden drop in water supply to zero. When an anomaly occurs, the system immediately flashes the equipment location and anomaly type on the monitoring screen, alerts on-duty personnel through audible and visual alarms, and records the anomaly information to the event database, including equipment identification, anomaly parameter name, value, occurrence time, and duration.

[0090] Example 4: SeeFigure 4 The anomaly identification unit and user access control module work together to achieve accurate identification of equipment anomalies and refined control of system permissions. The threshold configuration subunit within the anomaly identification unit sets normal range thresholds for various operating parameters of different types of equipment. The configuration interface provides two modes: static thresholds and dynamic thresholds. Static thresholds are suitable for equipment with small parameter fluctuations, such as setting the voltage threshold for ordinary lighting equipment to 220V±10%, i.e., 198V-242V; and the pressure threshold for fire pumps to 0.8MPa-1.2MPa. Dynamic thresholds are suitable for equipment whose parameters change with the environment or time, such as the temperature threshold for central air conditioning. The system analyzes historical operating data from the past 30 days to calculate the average temperature and fluctuation range for different time periods (e.g., weekdays 8:00-18:00, nighttimes 18:00-next day 8:00, weekends), automatically generating dynamic thresholds for each time period, and readjusting them every Monday morning based on the previous week's data. Threshold configurations support batch import and export. Administrators can save the threshold configuration for a certain type of equipment as a template and apply it to other equipment of the same type. Configuration changes take effect immediately and are logged.

[0091] The real-time comparison subunit compares the real-time collected parameter values ​​with the currently effective threshold point by point, performing a comparison for each collected parameter value. The formula for calculating the parameter deviation percentage is as follows:

[0092]

[0093] in, Indicates the percentage of parameter deviation. This represents the parameter values ​​collected in real time. This indicates the currently effective threshold (for thresholds with upper and lower limits, take the AND term). Threshold for consistent deviation direction, such as If it exceeds the upper limit This is the upper limit value. If it is below the lower limit (This is the lower limit value). Simultaneously, the system records the duration for which the parameter continuously exceeds the threshold, starting the timer from the first time the parameter exceeds the threshold until the timer stops when the parameter returns to the normal range. The comparison results are written to the monitoring data table in real time, including the device ID, parameter name, and... , , Duration of continuous anomalies and comparison time.

[0094] The event generation subunit generates an exception event work order when the triggering conditions are met. There are two types of triggering conditions: one is the percentage of parameter deviation. The work order is triggered by two main reasons: 1) the deviation exceeds a preset threshold (e.g., 15% for power equipment, 20% for water supply and drainage equipment); or 2) the duration of the anomaly reaches a preset threshold (e.g., 3 minutes for critical equipment, 10 minutes for general equipment). The work order includes the equipment's unique identifier (e.g., "Power-Transformer-001"), the name and value of the abnormal parameter (e.g., "Temperature: 95℃"), the time of occurrence accurate to the second, the anomaly level (categorized as urgent, important, and general based on the degree of deviation and equipment importance), and suggested handling measures. Suggested handling measures are generated based on historical handling records of similar anomalies, such as "Overheating: Check cooling fan" or "Underpressure: Check pipeline leaks." Once generated, the work order is automatically added to the maintenance task list, and a notification is sent to the corresponding maintenance personnel based on the anomaly level. Simultaneously, the equipment location is marked on the system map for quick location assistance.

[0095] The role definition unit in the user permission management module is used to create system operation roles. The role creation interface requires filling in the role name (e.g., "Property Maintenance Supervisor," "Security Specialist"), role description, and permission set. The permission set includes several sub-permissions: menu access permissions control the system menus the role can view, such as "Equipment Monitoring Menu" and "Resident Management Menu"; button operation permissions control the function buttons the role can use, such as "Add Resident," "Delete Equipment Record," and "Approve Service Request"; data query permissions limit the data range the role can access, such as "Data for Residents in This Building Only" and "All Equipment Operation Data"; and report export permissions control whether the role can export specific reports, such as "Monthly Energy Consumption Report" and "Resident Satisfaction Report." Permission configuration uses a checkbox method. Administrators select the corresponding permission items in the interface to create a permission set. Permission sets can be saved as role templates for reuse when creating similar roles later. Permission sets can be modified at any time after a role is created, and modifications are immediately applied to all users associated with that role.

[0096] The user allocation unit associates user accounts with roles. A user account can be associated with multiple roles, and its final permissions are the sum of the permissions of all associated roles. For example, if user "Zhang San" is associated with both the "Property Maintenance Worker" and "Night Shift Worker" roles, then its permissions include all permissions of both roles. When permissions of different roles conflict (e.g., one role has the "Delete Device Record" permission, while another role does not), the system adopts the setting with the broader permission scope, i.e., retaining the "Delete Device Record" permission. Association operations are performed in the user management interface. Administrators can select individual users to associate with roles one by one, or select multiple users to batch associate with the same role. During the association process, the system automatically checks the user account status (e.g., whether it is enabled), and only performs association operations on users with an enabled account. Association information is stored in the user role association table, including user ID, role ID, association time, and associated person. Batch unassociation is supported; after unassociation, user permissions are updated immediately, and the operation record is written to the permission change log.

[0097] The permission audit unit performs regular permission compliance audits. The audit cycle can be adjusted in the system settings, with the default being midnight on the 1st of each month. During the audit, the system checks for over-allocation of user permissions, such as the "Ordinary Resident" role being associated with the "Modify Property Fee Standard" permission; it checks for long-term inactivity of permissions by analyzing user operation logs, calculating the last usage time of each permission, and marking permissions that have not been used for three consecutive months; and it checks whether permissions match job responsibilities by comparing the user's department and position information with role permissions, such as the "Cleaning Staff" role not having the "View Resident Financial Data" permission. After the audit is completed, an audit report is generated. The report lists abnormal permission items in tabular form, including user ID, username, department, abnormal permission name, abnormal type, and suggested adjustment plan. The report is automatically sent to the system administrator's to-do list. The administrator can view the details and perform permission adjustment operations. After the adjustment, the system records the rectification results, including the adjustment time, permission changes before and after the adjustment, and the operator, forming a complete audit loop.

[0098] Example 5: The service process management module handles various service requests initiated by community residents, covering repair applications, complaints and suggestions, item repair requests, and venue reservations. Residents can submit service requests through various channels such as the community APP, WeChat mini-program, service hotline, or property management front desk. The system uniformly receives and enters these requests into the service process management module.

[0099] The request classification sub-unit automatically categorizes service requests based on their content characteristics. According to the urgency of the service, requests that may affect residents' basic living conditions, such as burst water pipes or short circuits, are marked as urgent requests; requests that do not involve safety or basic living guarantees, such as property fee inquiries or neighborhood noise complaints, are marked as routine requests; and requests that are not urgently needed, such as suggestions for community greening or event organization, are marked as low-priority requests. According to the type of facility involved, elevator malfunctions and broken lighting are categorized as public facilities; water pipe leaks and drainage blockages are categorized as water supply and drainage facilities; and surveillance malfunctions and access control malfunctions are categorized as security facilities. According to the department responsible for handling the requests, repair-related requests are assigned to the maintenance department, complaint and suggestion requests to the customer service department, venue reservation requests to the administration department, and safety-related requests to the security department. The classification results are displayed as tags in the service request form, and the urgency tags directly affect the processing order of the work order.

[0100] The intelligent dispatching subunit allocates service requests to the optimal personnel based on multi-dimensional factors. The current workload of each personnel is determined by counting the number of incomplete work orders. The system updates the number of pending work orders for each personnel in real time, prioritizing new work orders for personnel with lower workloads. Skill matching is achieved by comparing the personnel's skill tags with the request type. For example, personnel with the skill tag "Plumbing and Electrical Repair" are prioritized for plumbing and electrical fault requests, and personnel with the skill tag "Elevator Maintenance" are prioritized for elevator fault requests. The system calculates a matching score from 0 to 100 based on the matching degree, with higher scores indicating higher priority. Geographical location information is obtained through the location tracking of the personnel's mobile devices. The system calculates the straight-line distance between the personnel's current location and the service location (e.g., the entrance of a building unit), prioritizing closer locations. During comprehensive evaluation, the system assigns weights to workload, skill matching degree, and geographic location (e.g., skill matching degree 40%, workload 30%, geographic location 30%), calculates a comprehensive score for each personnel, and the person with the highest score is selected as the optimal personnel. After a work order is assigned, the system notifies the handler via app push notifications, SMS messages, etc., including service request details, location, and contact information. If the handler does not acknowledge receipt within 15 minutes, the system automatically reassigns the work order to the handler with the second-highest overall score, and records the first non-response in the handler's performance evaluation data.

[0101] The exception handling subunit monitors the processing status of service requests in real time and triggers corresponding mechanisms when processing timeouts or workflow anomalies occur. Processing timeout refers to a work order failing to complete within a preset processing time limit. Different types of work orders have different processing time limits; for example, emergency repair work orders have a time limit of 2 hours, while regular complaint work orders have a time limit of 24 hours. The system starts timing when the work order is successfully assigned, sending a reminder to the processing personnel when less than 30 minutes remain, and triggering an alert immediately after the timeout. Work order anomalies include situations such as a work order being stuck in a certain approval stage for more than 8 hours without being processed, the processing personnel submitting a processing result that fails the review and is not resubmitted, and data errors occurring in the work order information during system workflow. After the alert mechanism is activated, the system displays a red pop-up reminder on the processing personnel's APP interface, sends an SMS containing the work order number and timeout reminder to the processing personnel's mobile phone, and automatically raises the work order priority by one level (e.g., from regular to emergency). Abnormal situations are simultaneously reported to the handler's direct supervisor. The supervisor can view the work order details in the system and choose to take over the handling, reassign it to another person, or extend the handling time limit. The reason for the extension must be filled in, and the extension time limit cannot exceed 50% of the original time limit at a time. Every step of the abnormal handling process (such as the warning trigger time, the superior's handling method, and priority change records) is recorded in detail in the work order log. The log is archived along with the work order to facilitate subsequent querying of the integrity of the handling process.

[0102] The service process management module also includes a work order tracking function. Residents can use the community APP to check the current status (e.g., assigned, processing, pending confirmation, completed) and processing progress (e.g., repair personnel have departed, are inspecting, waiting for parts). After processing, the personnel upload the results (e.g., before-and-after photos, processing description). Residents can confirm the results and submit feedback (e.g., satisfied, neutral, dissatisfied) through the APP. The feedback serves as reference data for the personnel's performance evaluation. All service request data and processing records are permanently stored and support statistical queries based on time, type, processing result, etc., generating monthly and quarterly service quality reports.

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

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

Claims

1. A cloud-based smart community management system, characterized in that: include: The community basic data management module is used to maintain the static information and dynamic records required for the overall operation of the community. The static information includes the community's geographical area division, the distribution of public facilities, and the property management structure information. The dynamic records include resident registration data, vehicle entry and exit records, and service request processing results. The building structure information module is used to store the physical attribute data and resident association information of each building. The physical attribute data includes building number, number of units, floor height and unit distribution parameters. The resident association information includes unit resident list, property ownership status and resident family member information. The public equipment monitoring module is used to collect real-time operating status data and historical performance indicators of community public equipment. The real-time operating status data includes equipment operating power, temperature parameters and fault alarm signals, and the historical performance indicators include monthly energy consumption statistics, fault occurrence frequency and maintenance records. The cloud data interaction module is used to realize data transmission and synchronization between the local management system and the cloud server; The user permission management module is used to assign system operation permissions according to preset role types. The preset role types include system administrator, property management personnel, building manager, and ordinary resident. The operation permissions include data viewing scope, function usage permissions, and approval process configuration permissions.

2. The cloud-based smart community management system as described in claim 1, characterized in that, The community basic data management module includes: The information classification unit is used to divide community data into property management data, resident-submitted data, and system-automatically collected data according to the data generating entity. The record update unit is used to initiate the information update process when a data change instruction is received, and replace the historical records after verifying the validity of the new data through data verification rules. The version control unit is used to generate a version identifier for each data update, record the update time, the user who performed the operation, and the changes, forming a traceable version history log.

3. The cloud-based smart community management system as described in claim 1, characterized in that, The building structure information module includes: The structure editing unit provides a visual editing interface for the physical properties of buildings, supporting the addition of building records, modification of unit configurations, and deletion of abandoned building information; The resident association unit is used to establish a binding relationship between the house number and the resident's identity information, and supports many-to-many relationship configurations of a single resident associating with multiple houses and a single house associating with multiple residents. The status tag unit is used to dynamically update the property status tag based on the occupancy status, including vacant, owner-occupied, rented and for sale status, and to update it synchronously to the community data overview panel.

4. The cloud-based smart community management system as described in claim 2, characterized in that, The record update unit includes: The change detection subunit is used to monitor the community data storage directory in real time and trigger change notifications when file modification, addition, or deletion operations are detected. The data validation subunit is used to perform format validation, logical validation, and integrity validation on changed data. Format validation verifies whether the data fields meet the preset data type requirements, logical validation verifies whether there are contradictions in related data, and integrity validation verifies whether there are any missing required fields. The conflict resolution subunit is used to select the data version to retain according to preset priority rules when there is a conflict between local data and cloud-synchronized data. The priority rules include priority of the latest timestamp, priority of the credibility of the data source, and priority of manual review and confirmation.

5. The cloud-based smart community management system as described in claim 2, characterized in that, The version control unit includes: The version generation subunit is used to generate a unique version identifier by combining timestamps and random sequences, ensuring that the version numbers of different update operations are not duplicated; The logging sub-unit is used to write key information about each version update into the audit log, including the user ID of the operation, data snapshots before and after the update, and the IP address of the operation. The backtracking recovery subunit is used to support restoring data to a historical state based on version identifiers or points in time, and automatically creating a backup version of the current state during the recovery process.

6. The cloud-based smart community management system as described in claim 5, characterized in that, The system also includes: The data backup module is used to configure the automatic backup strategy for community data, including backup frequency, backup media, and backup retention duration. The backup execution module is used to periodically start data backup tasks according to the preset backup strategy, and perform full or incremental backups of community basic data, building information and equipment monitoring data. The backup verification module is used to perform integrity verification and availability testing on the generated backup files to ensure that the backup data can be restored normally. Integrity verification is achieved through checksum comparison, and availability testing is achieved by simulating the recovery process.

7. The cloud-based smart community management system as described in claim 1, characterized in that, The public equipment monitoring module includes: The equipment classification unit is used to divide community public equipment into power equipment, water supply and drainage equipment, security equipment and environmental monitoring equipment according to the equipment function type; The parameter acquisition unit is used to collect equipment operating parameters in real time through the Internet of Things interface, including voltage, current, flow rate, pressure, and temperature and humidity values. An anomaly identification unit is used to compare the collected real-time parameters with a preset normal range. When the parameters exceed the normal range, an anomaly event is generated. The anomaly events include parameter over-limit alarm, device offline alarm, and status change alarm.

8. The cloud-based smart community management system as described in claim 7, characterized in that, The anomaly detection unit includes: The threshold configuration subunit is used to configure independent normal range thresholds for various operating parameters of different types of equipment. It supports two configuration modes: static threshold and dynamic threshold. The dynamic threshold is automatically adjusted based on historical data statistical analysis. The real-time comparison subunit is used to compare the real-time collected parameter values ​​with the current effective threshold point by point, calculate the percentage of parameter deviation, and record the duration of continuous abnormality. The event generation subunit is used to generate an abnormal event work order containing the device identifier, abnormal parameters, occurrence time, and suggested handling measures when the parameter deviation percentage exceeds the deviation threshold or the duration of continuous abnormality reaches the duration threshold.

9. The cloud-based smart community management system as described in claim 1, characterized in that, The user access management module includes: The role definition unit is used to create system operation roles and configure role permission sets, which include menu access permissions, button operation permissions, data query permissions, and report export permissions. The user allocation unit is used to associate system user accounts with one or more roles to achieve role-based access control and support users to have combined permissions for multiple roles at the same time. The permission audit unit is used to periodically audit the compliance of user permission allocation, and to check for situations such as excessive permission allocation, long-term unused permissions, or permissions that do not match job responsibilities.

10. The cloud-based smart community management system as described in claim 1, characterized in that, The system also includes: The service process management module is used to process various service requests initiated by community residents, including repair requests, complaints and suggestions, item repair requests, and venue reservations. The service process management module includes: The request classification subunit is used to automatically classify request types based on the content characteristics of service requests. The classification criteria include the urgency of the service, the type of facilities involved, and the department to which the processing department belongs. The intelligent dispatching subunit is used to automatically allocate service requests to the best personnel based on the current workload, skill matching degree, and geographical location information of the processing personnel. The exception handling subunit is used to trigger an early warning mechanism and automatically escalate the alert to the superior processing node when a service request times out or a flow exception occurs. The early warning mechanism includes system message reminders, SMS notifications, and work order priority upgrades.

Images