Cross-system integrated dedusting data monitoring and layered linkage visualization device
By using a cross-system integrated dust removal data monitoring and hierarchical linkage visualization device, the problems of scattered data from multiple systems and weak visualization interaction have been solved, achieving efficient operation and maintenance and fault response, and reducing operation and maintenance costs and environmental risks.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- SHANXI TAIGANG STAINLESS STEEL CO LTD
- Filing Date
- 2026-01-15
- Publication Date
- 2026-05-08
AI Technical Summary
Existing industrial dust removal system monitoring devices suffer from problems such as scattered data from multiple systems, poor module coordination, and weak visualization interaction, resulting in high operation and maintenance costs, slow fault response, and difficulty in environmental risk management.
It adopts a cross-system integrated dust removal data monitoring and hierarchical linkage visualization device, which realizes data source management, standardized interface, dual-mode scheduling and hierarchical interaction through HD-SDK acquisition unit, SpringBoot synchronization unit, MyBatis-Plus storage unit and Web visualization unit. It supports automatic timed and manual triggered data synchronization and visualization interaction.
It enables collaborative analysis and real-time visualization of data from multiple systems, improving operation and maintenance efficiency by 60%, key data identification efficiency by 50%, reducing long-term operation and maintenance costs, and adapting to the upgrade needs of industrial dust removal systems.
Smart Images

Figure CN121995880A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of industrial equipment monitoring technology, and in particular to a cross-system integrated dust removal data monitoring system. Background Technology
[0002] In industrial production processes (such as metallurgy, machining, and building materials), dust removal systems are core equipment for controlling dust pollution, ensuring workshop air quality, and guaranteeing safe equipment operation. Real-time monitoring of their operational status is crucial for industrial production safety, environmental compliance, and equipment maintenance. However, existing industrial dust removal system (multi-system) monitoring devices suffer from three major technical deficiencies, making it difficult to meet the needs of efficient operation and collaborative management: Data is scattered across multiple systems, and collaborative analysis capabilities are lacking: Each dust removal system uses independent monitoring modules, without a unified data acquisition and management architecture. Maintenance personnel need to switch between multiple systems to obtain complete monitoring information, which is not only inefficient but also makes it impossible to correlate and analyze data from multiple systems, making it difficult to accurately assess the overall operating status of the dust removal system.
[0003] Poor module coordination and insufficient data flow stability: The existing monitoring devices' acquisition, synchronization, and storage modules are mostly simple functional superpositions, lacking standardized interface design, which makes the data flow link prone to interruption; and the scheduling mode is singular, only supporting automatic synchronization at fixed periods (such as sampling once every 2 hours), without a manual trigger scheduling channel, which cannot respond to the real-time data query needs in emergency scenarios such as equipment fault troubleshooting, further reducing the timeliness of operation and maintenance.
[0004] The visualization and interaction are weak, and the efficiency of key information identification is low: the front-end visualization interface is mostly a linear list of monitoring data (such as displaying parameters such as temperature and pressure only in chronological order), without hierarchical linkage design and interactive functions. It cannot achieve cross-time period data filtering, rapid location of abnormal data, and also lacks practical functions such as data export and real-time refresh. Some technical solutions that focus on the monitoring of a single device (such as the "an industrial dust collector fault location monitoring device" disclosed in Chinese utility model patent CN222738736U) only locate the fault point of a single dust collector and do not involve the visual collaborative display of data from multiple systems. It cannot solve the pain point of "inaccurate key data and inability to extract useful information" in multi-system monitoring scenarios. Summary of the Invention
[0005] The technical problem to be solved by this invention is: how to solve the problems of high operation and maintenance costs, slow fault response, and difficulty in environmental risk management caused by the defects of existing dust removal system monitoring devices.
[0006] The technical solution adopted in this invention is: a cross-system integrated dust removal data monitoring and hierarchical linkage visualization device, comprising multiple dust removal systems and a server. The monitoring points of each dust removal system are electrically connected to the server. The server is equipped with an HD-SDK acquisition unit, a SpringBoot synchronization unit, a background control unit, a MyBatis-Plus storage unit, a BaseMapper data operation module, and a Web visualization unit. The HD-SDK acquisition unit includes an HDDataConnection module, an HDTagManager tag management module, and an HDDataProvider data query module. The HDDataConnection module establishes an encrypted communication link through a triple authentication interface of IP, port, account, and password to ensure data transmission security. The HDTagManager module has a built-in unified tag point mapping table with a one-to-one correspondence between "TABLE_FIELD_NAME" and "TAG_NAME", providing a unified mapping table for monitoring each dust removal system. The system assigns unique identifiers to each data point to ensure consistent data management. The HDDataProvider module uses tagIDs to collect raw data from various dust removal systems in batches, breaking down data isolation barriers between systems and providing a standardized data foundation for collaborative analysis. The SpringBoot synchronization unit integrates an annotation-based timing module, an asynchronous execution module, a data conversion module, and an exception handling module. The annotation-based timing module uses annotations to achieve automatic hourly synchronization. The asynchronous execution module allows tasks to run independently, avoiding main process blocking. The data conversion module calls the BeanMapConvertUtil tool to map the collected data into entity class objects, formats them with BigDecimal to retain two decimal places, ensuring data accuracy. The exception handling module uses the HD-SDKException capture structure to record exception logs and skip fault monitoring points, ensuring continuous synchronization. The backend control unit includes a dedicated RestController interface module and a task scheduling module. The interface module, combined with the tags_task() method encapsulated by the task scheduling module, forms a dual-mode scheduling architecture of "automatic scheduling + manual triggering" with the Spring Boot synchronization unit. This not only meets routine operation and maintenance needs but also adapts to emergency query scenarios. Each unit establishes a connection through the MyBatis-Plus standardized data interface and the RestController dedicated interface module to achieve stable data flow between modules and reduce the risk of failure.
[0007] The monitoring points include those for the motors, fans, dust collectors, and thin oil stations of each dust removal system.
[0008] The MyBatis-Plus storage unit uses the MySQL-InnoDB engine to design structured tables. The core fields include a unique identifier (UUID), a mapping field name (TABLE_FIELD_NAME), a monitoring point tag name (TAG_NAME), formatted data (DATA_VALUE), and a recording time (recordDate / recordTime). The unique mapping between TABLE_FIELD_NAME and TAG_NAME enables data traceability across the three systems.
[0009] The BaseMapper data operation module provides batch insertion and query interfaces, providing an efficient link for data writing in the synchronization unit and data reading in the visualization unit, avoiding data call delays.
[0010] The web visualization unit includes a title linkage area, a form interaction area, a pagination control area, and a record set display area. The title linkage area displays the system name and links to a date picker, supporting data filtering across time periods. The form interaction area has a date selection text box on the left and three function buttons on the right: query, export, and tag refresh, triggering data filtering, export, and real-time updates. The pagination control area supports batch display of massive amounts of data (10 records per page) to improve viewing convenience. The record set display area adopts a hierarchical structure of "system-device-monitoring item," with each monitoring item bound to anomaly highlighting rules (e.g., automatic highlighting of bearing temperatures > 80℃). All functional areas are linked through data interfaces, forming a complete interactive loop of "filtering-querying-displaying-exporting-refreshing," improving the efficiency of key data identification.
[0011] The beneficial effects of this invention are as follows: Based on standardized interfaces (such as the MyBatis-Plus BaseMapper interface and the RestController-specific interface) and unified tag point mapping rules, when adding new monitoring points, only tag information needs to be added to the mapping table. When expanding to a new dust removal system, there is no need to reconstruct the core architecture; it can be directly connected to the closed-loop system through standardized interfaces. Compared with the "customized modification" of existing technologies, this solution can flexibly adapt to the upgrade needs of industrial dust removal systems, avoid the need for complete device replacement due to system iteration, and significantly reduce long-term operation and maintenance costs. Attached Figure Description
[0012] Figure 1 This is a schematic diagram of the overall structure of the present invention; Figure 2 This is a schematic diagram of the HD-SDK acquisition unit in an embodiment of the present invention. Detailed Implementation
[0013] This embodiment uses the daily operation and maintenance scenario of the smelting workshop in the south area of a steel plant as an example for illustration.
[0014] like Figure 1 and 2 As shown, this embodiment of a cross-system integrated dust removal data monitoring and hierarchical linkage visualization device includes three dust removal systems and one server. The monitoring points of each dust removal system are electrically connected to the server. The three dust removal systems are a roof-mounted dust removal system, a pretreatment dust removal system, and a VOD bag filter dust removal system. Each system is independently monitored and controlled using different systems. The dust removal system suffers from high operation and maintenance costs, slow fault response, and difficulty in environmental risk management.
[0015] The server is equipped with an HD-SDK acquisition unit, a Spring Boot synchronization unit, a backend control unit, a MyBatis-Plus storage unit, a BaseMapper data operation module, and a Web visualization unit.
[0016] The HD-SDK acquisition unit includes an HDDataConnection module, an HDTagManager module, and an HDDataProvider module. The HDDataConnection module establishes an encrypted communication link through a triple authentication interface (IP, port, account, password) to ensure data transmission security. The HDTagManager module has a built-in unified tag mapping table that maps TABLE_FIELD_NAME to TAG_NAME, assigning unique identifiers to monitoring points of each dust removal system to achieve data source management. The HDDataProvider module collects raw data from each dust removal system in batches using tagIDs, breaking down data isolation barriers between multiple systems and providing a standard for collaborative analysis. The system establishes a standardized data foundation. The Spring Boot synchronization unit integrates an annotation-based timing module, an asynchronous execution module, a data transformation module, and an exception handling module. The annotation-based timing module enables automatic hourly synchronization using annotations. The asynchronous execution module allows tasks to run independently, avoiding main process blocking. The data transformation module uses the BeanMapConvertUtil tool to map collected data into entity class objects, formatting them with BigDecimal to retain two decimal places to ensure data accuracy. The exception handling module uses the HD-SDKException capture structure to record exception logs and skip fault monitoring points, ensuring continuous synchronization. The backend control unit includes a dedicated RestController interface module and a task scheduling module. The RestController interface module, combined with the tags_task() method encapsulated in the task scheduling module, forms a dual-mode scheduling architecture of "automatic timing + manual triggering" with the Spring Boot synchronization unit, meeting both routine maintenance needs and adapting to emergency query scenarios. Connections between units are established through the MyBatis-Plus standardized data interface and the RestController dedicated interface module, enabling stable data flow between modules and reducing the risk of failure.
[0017] The entire process logic, from "data acquisition - synchronization - storage - visualization interaction", includes both automatic and manual scheduling modes.
[0018] Cross-system data acquisition and synchronization Automatic scheduled synchronization (for routine maintenance scenarios) Triggering conditions: At the exact hourly times of 8:00, 9:00, and 10:00 each day, the @Scheduled annotation of the Spring Boot Synchronous Unit automatically triggers the tags_task() method; Data Acquisition: The HD SDK acquisition unit uses the HDDataProvider.querySnapshotByTagID() method to batch collect snapshot data of tag points in the three major systems (such as the temperature of the roof fan bearing at 72℃ and the pressure difference of the pretreatment dust collector at 3.2kPa). Data processing: The asynchronous execution module processes data independently, mapping the raw data to RfFdRoomPreVodDustRecords entity class objects through BeanMapConvertUtil, and formatting it using BigDecimal.setScale(2,RoundingMode.HALF_UP) (e.g., 3.2kPa is retained as 3.20kPa). Data storage: The MyBatis-Plus storage unit uses the BaseMapper.batchInsert() method to write formatted data into a MySQL structured table, recording time fields such as recordDate=2025-11-19 and recordTime=08:00:00.
[0019] Manually trigger synchronization (for emergency troubleshooting scenarios) Triggering scenario: Maintenance personnel discover abnormal vibration of the VOD bag filter system fan and need to obtain data in real time to troubleshoot the fault; Operation steps: In the "Form Interaction Area" of the Web visualization interface, click the "Tag Refresh" button. The front end will call the backend / rfFdRoomPreVodDustRecords / tagsAdd interface via AJAX request. Synchronous execution: The background control unit calls the tags_task() method, skipping the timer period and directly triggering the collection-processing-storage process. The entire process takes ≤3 seconds. Results feedback: The record set table in the visualization interface is refreshed in real time, showing the vibration value of the VOD bag filter system fan (e.g., 4.5mm / s, which does not exceed the threshold of 5.0mm / s), thus eliminating the risk of failure.
[0020] Layered Linkage Visual Interaction Taking the query "Query preprocessed system data from 08:00 to 09:00 on November 19, 2025" as an example, the interaction process is explained as follows: Filter settings: In the date selector of the "Title Linkage Area", enter the start time "2025-11-19 08:00:00" and the end time "2025-11-19 09:00:00", and select the system type "Preprocessing System"; Data Query: Click the "Query" button in the "Form Interaction Area". The Web visualization unit calls the query interface of the MyBatis-Plus storage unit through DataQueryService to filter the preprocessed system data for the corresponding time period. Data Display: The record set table displays 8 parameters of the pretreatment system, including dust collector differential pressure (3.20 kPa) and motor temperature (65℃). There are no abnormal data (not highlighted in red). Data Export: Click the "Export" button to generate an Excel file (named "Preprocessing System_202511190800-0900.xlsx") containing 12 data records for subsequent maintenance report statistics; Pagination operation: If the query results exceed 10 (e.g., 15), the "Pagination Control Area" will automatically display "Current Page 1 of 2". Click the ">" button to switch to page 2 and view the remaining 5 data.
[0021] 3. Exception handling and fault tolerance mechanism Data Acquisition Exception Handling: If a tag point (such as RT_FAN_TEMP) in the roof canopy system fails to acquire data due to PLC communication interruption, the exception handling module of the HD SDK acquisition unit will capture the HDSdkException, record "tagID=RT001, exception information: PLC connection timeout" in the log, and skip that tag point to continue synchronizing the data of the other 127 tag points, ensuring that the overall synchronization task is not interrupted; Storage exception handling: If the database server is temporarily offline, the Spring Boot synchronization unit will temporarily store the formatted data in a local cache (Redis). Once the database connection is restored, the data will be automatically written in batches to avoid data loss. Visualization error handling: If the visualization interface fails to load, the front end will automatically display the message "Data loading error, please click refresh to retry" and provide a "Refresh Interface" button. Clicking the button will re-call the query interface and restore the data display.
[0022] The above embodiments verify the feasibility of the present invention: modular deployment achieves physical isolation and logical collaboration among units; dual-mode scheduling and hierarchical interaction meet the needs of routine operation and maintenance and emergency troubleshooting; and a fault-tolerant mechanism ensures stable operation of the device. In practical applications, this device can achieve integrated management of data from three major dust removal systems, improving operation and maintenance efficiency by 60% and key data identification efficiency by 50%, fully adapting to the monitoring needs of industrial dust removal systems.
Claims
1. A cross-system integrated dust removal data monitoring and hierarchical linkage visualization device, characterized in that: The system comprises multiple dust removal systems and a server. Monitoring points from each dust removal system are electrically connected to the server. The server is equipped with an HD-SDK acquisition unit, a Spring Boot synchronization unit, a backend control unit, a MyBatis-Plus storage unit, a BaseMapper data operation module, and a Web visualization unit. The HD-SDK acquisition unit includes an HDDataConnection module, an HDTagManager module, and an HDDataProvider module. The HDDataConnection module establishes an encrypted communication link through a triple authentication interface (IP, port, account, and password) to ensure secure data transmission. The HDTagManager module has a built-in unified tag mapping table that maps "TABLE_FIELD_NAME" to "TAG_NAME" one-to-one, assigning unique identifiers to monitoring points of each dust removal system to achieve data source management. The HDDataProvider module collects raw data from various dust removal systems in batches using tagIDs, breaking down data isolation barriers between multiple systems and providing a standardized data foundation for collaborative analysis. The SpringBoot synchronization unit integrates an annotation-based timing module, an asynchronous execution module, a data conversion module, and an exception handling module. The annotation-based timing module uses annotations to achieve automatic hourly synchronization. The asynchronous execution module enables independent task execution, avoiding main process blocking. The data conversion module calls the BeanMapConvertUtil tool to map the collected data into entity class objects, formats them with BigDecimal to retain two decimal places, ensuring data accuracy. The exception handling module uses the HD-SDKException capture structure, records exception logs, and skips fault monitoring points to ensure continuous synchronization. The backend control unit includes a RestController dedicated interface module and a task scheduling module. The interface module, combined with the tags_task() method encapsulated by the task scheduling module, forms a dual-mode scheduling architecture of "automatic scheduling + manual triggering" with the Spring Boot synchronization unit. This not only meets routine operation and maintenance needs but also adapts to emergency query scenarios. Each unit establishes a connection through the MyBatis-Plus standardized data interface and the RestController dedicated interface module to achieve stable data flow between modules and reduce the risk of failure.
2. The cross-system integrated dust removal data monitoring and hierarchical linkage visualization device according to claim 1, characterized in that: The monitoring points include those for the motors, fans, dust collectors, and thin oil stations of each dust removal system.
3. The cross-system integrated dust removal data monitoring and hierarchical linkage visualization device according to claim 1, characterized in that: The MyBatis-Plus storage unit uses the MySQL-InnoDB engine to design structured tables. The core fields include a unique identifier (UUID), a mapping field name (TABLE_FIELD_NAME), a monitoring point tag name (TAG_NAME), formatted data (DATA_VALUE), and a recording time (recordDate / recordTime). The unique mapping between TABLE_FIELD_NAME and TAG_NAME enables data traceability across the three systems.
4. The cross-system integrated dust removal data monitoring and hierarchical linkage visualization device according to claim 1, characterized in that: The BaseMapper data operation module provides batch insertion and query interfaces, providing an efficient link for data writing in the synchronization unit and data reading in the visualization unit, avoiding data call delays.
5. The cross-system integrated dust removal data monitoring and hierarchical linkage visualization device according to claim 1, characterized in that: The Web visualization unit includes a title linkage area, a form interaction area, a pagination control area, and a record set display area. The title linkage area displays the system name and links to a date picker, supporting data filtering across time periods. The form interaction area has a date selection text box on the left and three function buttons on the right: query, export, and tag refresh, which trigger data filtering, export, and real-time updates. The pagination control area supports batch display of massive amounts of data, up to 10 records per page, improving viewing convenience. The record set display area adopts a hierarchical structure of "system-device-monitoring item," with each monitoring item bound to anomaly highlighting rules (such as automatic highlighting of bearing temperature > 80℃). Each functional area is linked through data interfaces to form a complete interactive loop of "filtering-querying-displaying-exporting-refreshing," improving the efficiency of key data identification.
Citation Information
Patent Citations
Dust collector fault location device
CN222738736U