A low-flow data transmission method for a shot blasting machine based on an MQTT protocol

Abstract

The application discloses a low-flow data transmission method of a shot blasting machine based on an MQTT protocol and concretely relates to the field of digital information transmission, and comprises the following steps: collecting multiple operation parameters of the shot blasting machine, performing parameter validity verification on an edge configuration side, and simultaneously establishing a data communication connection; setting a differential trigger threshold value for each operation parameter and acquiring a parameter absolute change amount, determining a data reporting trigger state according to a comparison result of the change amount and the threshold value; dynamically adjusting a heartbeat keep-alive period according to an idle time length without continuous reporting, and constructing a data transmission mechanism in combination with a simplified message format for transmitting only changed parameters; and the application deeply integrates data transmission and operation and maintenance alarm, effectively improves equipment operation and maintenance efficiency and product iteration speed, and significantly improves the problem that transmission and operation and maintenance are independent of each other and operation and maintenance management efficiency is low.

Description

Technical Field

[0001] This invention relates to the field of digital information transmission technology, and more specifically, to a low-traffic data transmission method for shot blasting machines based on the MQTT protocol. Background Technology

[0002] Uploading equipment data to the cloud is the core foundation for achieving remote monitoring and intelligent operation and maintenance. Message queue telemetry transmission protocols are widely used in industrial equipment data transmission scenarios due to their lightweight and low-overhead characteristics. Shot blasting machines, as core surface treatment equipment in the casting and machining industries, come in various models such as hook-type, crawler-type, and through-type. Remote transmission of their operating data is a necessary link in realizing the full life cycle management of the equipment. Currently, the cloud-based data upload for shot blasting machines generally adopts a "PLC controller + external gateway" architecture. The gateway collects the operating data of the PLC controller, converts it into the corresponding protocol, and uploads it to the cloud to achieve remote monitoring of equipment status.

[0003] While existing technologies can achieve remote data transmission from shot blasting machines, they still have several shortcomings in practical engineering applications. Firstly, current solutions require additional hardware gateways and modifications to the PLC controller's underlying program to adapt to gateway communication. This is costly, time-consuming, and lacks compatibility with different shot blasting machine models, making rapid mass deployment difficult. Furthermore, general message transmission often uses a fixed-period full-data reporting mode. During shot blasting machine operation, numerous parameters such as current, speed, air pressure, and material level need to be collected. High-frequency full-data reporting generates a large amount of redundant data, resulting in high monthly traffic per device and increased resource overhead for cloud storage and processing. Secondly, industrial sites commonly experience network fluctuations and temporary network outages, and existing transmission solutions lack local caching mechanisms. The lack of standardized time-series management makes it easy for duplicate and out-of-series data to be retransmitted after network outages, making it difficult to guarantee data integrity and consistency. At the same time, in the case of a two-tier tenant scenario for equipment manufacturers and end customers, the existing solution only adopts basic account permission isolation, lacking multi-layer isolation protection of message topic hierarchy, database storage and data content, making it difficult to meet the compliance requirements of industrial IoT. In addition, the existing data transmission system and equipment operation and maintenance alarm system are independent of each other, with alarm data and operation data belonging to different transmission links. The alarm real-time performance is insufficient, and it is impossible to automatically generate operation and maintenance work orders based on transmission data in a closed-loop process, making it difficult to improve operation and maintenance efficiency.

[0004] To address the shortcomings of existing technologies, this invention proposes a low-flow data transmission method for shot blasting machines based on the MQTT protocol. Utilizing the existing PLC controller and MCGS configuration panel hardware of the shot blasting machine, and without modifying the underlying equipment program, this method employs differential trigger threshold triggering, adaptive heartbeat, local ring buffer unit for data transmission, and multi-tenant multi-layer isolation techniques to achieve low-flow, highly reliable, and highly secure data transmission for shot blasting machines. Furthermore, it integrates closed-loop management of operation and maintenance alarms, adapting to the common practical needs of industrial sites. Summary of the Invention

[0005] To overcome the aforementioned deficiencies of the prior art, the present invention provides a low-traffic data transmission method for shot blasting machines based on the MQTT protocol, which solves the problems mentioned in the background art through the following scheme.

[0006] To achieve the above objectives, the present invention provides the following technical solution: a low-traffic data transmission method for shot blasting machines based on the MQTT protocol, comprising: S1: Collect multiple operating parameters of the shot blasting machine and perform parameter validity verification on the edge configuration side, while establishing a data communication connection; S2: Set differential trigger thresholds for each operating parameter and obtain the absolute change of the parameter. Determine the data reporting trigger status based on the comparison between the change and the threshold. S3: Dynamically adjust the heartbeat keep-alive cycle based on the continuous idle time without reporting, and construct a data transmission mechanism by combining a simplified message format that only transmits changing parameters; S4: In the event of a network outage, data to be transmitted is temporarily stored in a local ring buffer unit. After the network is restored, the data is retransmitted in ascending order of timestamp and data deduplication is performed in the cloud. S5: Adopts a three-tier architecture to build a multi-tenant data security protection system, which is suitable for two-tier tenant application scenarios; S6: The cloud-based rule engine sorts all received data by type and performs time-series storage and alarm data forwarding operations respectively. S7: Triggers tiered alarms based on transmitted operational data and automatically generates maintenance work orders, building an operational management link from alarms to archiving.

[0007] Preferably, the acquisition method for the multiple operating parameters is as follows: the PLC controller acquires the parameters in real time at a 100ms acquisition cycle, specifically including shot blaster current I, shot blaster speed n, shot material level h, dust collector air pressure P, main motor temperature T, equipment operating status code S, equipment output, and cumulative running time H; the parameter validity verification method is as follows: the MCGS configuration panel compares the received parameter values ​​with the corresponding physical range, and data exceeding the range is judged as abnormal values ​​and filtered out, while valid data is retained for subsequent processing; the data communication connection method is as follows: the field control device is the PLC controller, and the configuration device is the MCGS configuration panel. The two establish a physical connection through industrial Ethernet, and the communication variable mapping is completed only through the configuration configuration of the MCGS configuration panel to realize the transmission of operating parameters from the PLC controller to the MCGS configuration panel. No changes are made to the underlying operating logic and control code of the PLC controller during the transmission process.

[0008] Preferably, the differential trigger thresholds are set as follows: the MCGS configuration panel configures a differential trigger threshold for each operating parameter separately. Specifically, the differential trigger threshold for shot blasting current is 0.5A, the differential trigger threshold for shot blasting speed is 10r / min, the differential trigger threshold for shot level is 5mm, the differential trigger threshold for dust collector air pressure is 20Pa, and the differential trigger threshold for main motor temperature is 1... The equipment output differential trigger threshold is 1 unit, the cumulative runtime differential trigger threshold is 0.1 hours, and the equipment operation status code is a discrete enumeration quantity. No numerical differential trigger threshold is set. A change in the status code triggers a report. The method for determining the data reporting trigger status is as follows: when the absolute change of any parameter is greater than or equal to its corresponding differential trigger threshold, or when the absolute change of the equipment operation status code is not 0, a data report is triggered. Otherwise, no report is triggered, and only the current parameter value in the local cache is updated.

[0009] Preferably, the dynamic adjustment method of the heartbeat keep-alive cycle is as follows: Define the idle duration without continuous trigger reporting and the heartbeat cycle parameter; the MCGS configuration panel linearly adjusts the heartbeat cycle based on the idle duration and sets upper and lower limit constraints; the adjustment formula is as follows: In the formula, This is the input value, representing the duration of continuous idle time without triggering a report; is the input value, representing the initial heartbeat cycle; k is the input value, representing the heartbeat step size coefficient; The input value represents the upper limit of the heartbeat cycle. The input value represents the lower limit of the heart rate cycle. The output represents the adjusted heartbeat period. The dynamic adjustment of the heartbeat period follows the principle of prioritizing connection reliability and secondarily optimizing traffic. As the idle time increases, the heartbeat period increases linearly until it reaches the upper limit. The upper limit of the heartbeat period is set to 120s, which conforms to the general configuration that the timeout of an industrial IoT NAT session is usually no less than 300s, reserving sufficient margin to ensure connection activity. When data reporting is triggered, the idle time is cleared to zero, and the heartbeat period returns to the initial value. The simplified message format for transmitting only changed parameters is as follows: the message content only includes the device's unique identifier, data timestamp, the identifier of the changed parameter and its corresponding value. Parameters that have not changed are not included in the message. The message publication adopts the QoS1 service quality level.

[0010] Preferably, the traffic calculation method of the data transmission mechanism is as follows: the application layer transmission rate is obtained by summing the data packet traffic and heartbeat packet traffic respectively, and then the monthly traffic of a single device is calculated according to the standard natural month, wherein the application layer data transmission rate is calculated as follows: In the formula, f is the input quantity, representing the average data reporting frequency; L is the input quantity, representing the effective payload length of a single data report; This is an input value representing the fixed header length of the Message Queue Telemetry Transport Protocol (MQTP). The input value represents the total length of a single heartbeat message; B is the input, representing the heartbeat cycle; B is the output, representing the data transmission rate of the application layer of the message queue telemetry transport protocol.

[0011] Preferably, the local circular buffer unit temporarily stores data to be transmitted in the following way: the MCGS configuration panel has a built-in local circular buffer unit with a buffer capacity of 10,000 data records. Each record contains a timestamp and a complete reported data frame. This capacity corresponds to a maximum temporary storage time of approximately 16 minutes under a 100ms acquisition cycle. The network connection status is detected by heartbeat response. If no response is received from the cloud after three consecutive heartbeat messages based on the initial heartbeat cycle, it is determined that the network is disconnected. During the network disconnection period, all data triggered for reporting and heartbeat messages are written to the local circular buffer unit in the order of timestamps. When the local circular buffer unit is full, new data overwrites it. The earliest historical data ensures that the local circular cache unit always stores the latest operating data. The method of supplementing data in ascending order of timestamp is as follows: after the network is restored and the message queue telemetry transmission protocol connection is re-established, the MCGS configuration screen will sequentially supplement the historical data in the local circular cache unit to the cloud in ascending order of timestamp, with the supplementation rate set to 50 records / second. The method of data deduplication is as follows: when the cloud EMQX message broker receives the supplemented data, it will perform deduplication based on the device's unique identifier and the data timestamp. For data records of the same device with the same timestamp, only the first received record will be retained, and subsequent duplicate records will be discarded.

[0012] Preferably, the three-tier architecture includes topic permission isolation, database row-level isolation, and data content anonymization. The topic permission isolation is implemented as follows: the EMQX message broker adopts a layered topic design, with a topic format of tenant / {tenant unique identifier} / device / {device unique identifier} / data, where the tenant unique identifier is the tenant's unique identification code, and the device unique identifier is the device's unique identification code. The multi-tenant management module assigns independent topic subscription and publishing permissions to each tenant. Tenants can only access the topic data corresponding to their own tenant unique identifier and cannot access it across tenants. The database row-level isolation is implemented as follows: runtime data storage uses the TDengine time-series database. Each data record is associated with a corresponding tenant unique identifier field. All data query interfaces forcibly verify the tenant unique identifier parameter and only return data records matching the requested tenant unique identifier. The data content anonymization is implemented as follows: for terminal customer sub-tenants, two sensitive parameters—device output and cumulative runtime—are anonymized with a fixed offset. The anonymization formula is: In the formula, The input value represents the original value of the sensitive parameter; This is an input value representing a fixed offset specific to each tenant; The output represents the value displayed externally after anonymization. The manufacturer super tenant has full access to the original data, while the end-customer sub-tenant can only access the anonymized data. The multi-tenant data security protection system is constructed by sequentially layering topic permission isolation, database row-level isolation, and data content anonymization from the transport layer to the storage layer and then to the application layer to form a three-layer protection architecture. The adaptation rules for the two-layer tenant application scenario are as follows: the system adapts to both manufacturer super tenants and end-customer sub-tenants, each corresponding to different data access permissions and data ranges.

[0013] Preferably, the type-based traffic splitting is implemented as follows: the cloud-based rule engine module receives all data forwarded by the EMQX message agent and classifies it into two categories based on the data's attributes and triggering conditions: equipment operating status data and abnormal alarm data. The specific rules for time-series storage are as follows: for equipment operating status data, it is directly written into the TDengine time-series database. The storage strategy is as follows: the storage period for three types of high-frequency changing data, namely shot blaster current, shot blaster speed, and equipment output, is 1 year; the storage period for four types of low-frequency changing data, namely shot material level, dust collector air pressure, main motor temperature, and cumulative running time, is 3 years; and the storage period for equipment operating status codes is 3 years. The specific rules for alarm data forwarding are as follows: for abnormal data that meets the alarm triggering conditions, it is forwarded to the maintenance work order module and enters the alarm processing flow.

[0014] Preferably, the specific rules for triggering the graded alarms are as follows: Preset alarm triggering conditions specific to the shot blasting machine, including emergency stop alarm, motor overcurrent alarm, abnormal air pressure alarm, low material level alarm, and consumable lifespan expiration warning. Specifically, the motor overcurrent alarm triggering condition is that the shot blaster current is greater than 45A; the abnormal air pressure alarm triggering condition is that the dust collector air pressure is less than 800Pa or greater than 1500Pa; the low material level alarm triggering condition is that the shot level is less than 100mm; and the consumable lifespan expiration warning triggering condition is that the cumulative running time reaches the corresponding consumable's rated lifespan threshold. The alarm levels are divided into four levels: emergency stop alarm and motor overcurrent alarm are emergency level; abnormal air pressure alarm is important level; low material level alarm is general level; and consumable lifespan expiration warning is reminder level. The maintenance work order generation method is as follows: after an alarm is triggered, the maintenance work order module automatically generates a maintenance work order. The work order content includes the unique identifier of the equipment, the geographical location of the equipment, the alarm type, the alarm time, and the recommended handling solution. The work order information is pushed to the corresponding channel according to the alarm level. Emergency alarms are pushed to the maintenance manager via SMS, important alarms are pushed to maintenance personnel via WeChat mini program, and general and warning alarms are displayed through the web management terminal. The maintenance management link is constructed as follows: the work order execution is a closed-loop process of automatic dispatch, on-site handling, acceptance confirmation, and archiving statistics. After the work order is archived, the fault data is synchronously updated to the equipment health file. The fault statistics results are periodically output to the product development department to support the product optimization design of the shot blasting machine.

[0015] The technical effects and advantages of this invention are as follows: 1. This invention relies on the existing PLC controller and MCGS configuration screen hardware of the shot blasting machine. No additional gateway equipment is required, and no modification to the underlying program of the PLC controller is required. The message queue telemetry transmission protocol data can be uploaded to the cloud simply by configuring the MCGS configuration screen. It is compatible with all types of shot blasting machines, including hook-type, crawler-type, and through-type machines. This significantly reduces deployment and modification costs, shortens the batch deployment cycle, and significantly improves the problems of large hardware modification, long deployment cycle, and poor machine compatibility of existing solutions. 2. This invention adopts a combined low-traffic transmission mechanism of differential trigger threshold triggering reporting, adaptive heartbeat keep-alive, and simplified message format. Data is only reported when the parameter change reaches the threshold. The heartbeat cycle is dynamically extended during idle periods, effectively eliminating redundant transmission data. The monthly traffic of a single device can be stably controlled within 50MB, significantly reducing traffic costs and cloud storage resource consumption, and significantly improving the problems of large traffic and redundant data in the general full-volume reporting mode. 3. This invention designs a network outage resume transmission scheme with local ring buffer unit, timestamp-based retransmission, and cloud deduplication. In the case of short-term network fluctuations and temporary network outages in industrial sites, it can effectively ensure data integrity and time sequence consistency. The retransmission process rate is controllable, avoiding sudden traffic surges, improving the reliability and stability of data transmission, and significantly improving the problems of data loss and retransmission duplication and disorder in network outage scenarios. 4. This invention constructs a three-layer multi-tenant protection system with topic permission isolation, database row-level isolation, and data content anonymization. It is adapted to the two-layer tenant architecture of manufacturers and end customers, and realizes full-link logical data isolation from message transmission and data storage to content display. It meets the data security compliance requirements of industrial IoT and significantly improves the problems of coarse granularity and insufficient security of existing multi-tenant isolation solutions. 5. This invention deeply integrates data transmission with operation and maintenance alarms. Based on the transmitted data, it realizes a dedicated hierarchical alarm for shot blasting machines, automatically generates operation and maintenance work orders and pushes them through multiple channels, forming a closed loop of the entire process of dispatching, processing, acceptance and archiving. Fault statistics can support product optimization, effectively improve equipment operation and maintenance efficiency and product iteration speed, and significantly improve the problems of independent transmission and operation and maintenance and low operation and maintenance management efficiency. Attached Figure Description

[0016] Figure 1 This is a flowchart of the method steps of the present invention; Figure 2 This is a schematic diagram of the S3 adaptive heartbeat keep-alive and simplified message transmission steps of the present invention. Detailed Implementation

[0017] 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.

[0018] This method is implemented based on a four-layer architecture: field device layer, edge configuration layer, network transmission layer, and cloud service layer. Each layer of network elements executes a complete process of data acquisition, edge processing, transmission control, cloud isolation, offloading and storage, and operation and maintenance closed loop according to the data flow direction. The specific implementation process of each step is as follows: As attached Figure 1 The method for low-traffic data transmission in a shot blasting machine based on the MQTT protocol, as shown, includes the following steps: S1: Collect multiple operating parameters of the shot blasting machine and perform parameter validity verification on the edge configuration side, while establishing a data communication connection; This step is jointly executed by the programmable logic controller (PLC) at the field device layer and the configuration display screen at the edge configuration layer. It is executed during the entire operation of the shot blasting machine, and the execution scenario is the shot blasting machine equipment side in an industrial production site. The specific implementation process is as follows: The PLC collects all operating parameters in real time from various detection points on the shot blasting machine body according to a fixed acquisition cycle. This includes electrical parameters, motion parameters, material parameters, process parameters, and operating status indicators of the core components of the equipment. After acquisition, the PLC transmits all parameters to the configuration display screen via an industrial Ethernet network. The entire communication process only completes variable mapping and connection through the configuration configuration of the configuration display screen, without modifying the underlying operating program and control logic of the PLC. After receiving the parameters, the configuration display screen compares each parameter with its corresponding normal physical range. Parameters exceeding the range are judged as abnormal data and directly filtered out, retaining only valid parameters for subsequent processing.

[0019] In this embodiment, it should be specifically noted that the acquisition method for the various operating parameters is as follows: the PLC controller acquires the parameters in real time at a 100ms acquisition cycle. Specifically, these parameters include: shot blasting current I (A, range 0~50A); shot blasting speed n (r / min, range 0~3000r / min); shot level h (mm, range 0~1000mm); dust collector air pressure P (Pa, range 0~2000Pa); and main motor temperature T (…). Measuring range 0~150 The equipment operating status code S is an unsigned integer, with values ​​corresponding to four states: standby, running, fault, and stop. Equipment output Q is in units of pieces, with a range of 0-999 pieces. Cumulative running time H is in hours, with a range of 0-9999 hours. The parameter validity verification method is as follows: the MCGS configuration panel compares each received parameter value with its corresponding physical range. Data exceeding the range is judged as an anomaly and filtered out, while valid data is retained for subsequent processing. The data communication connection method is as follows: the field control device is a PLC controller, and the configuration device is an MCGS configuration panel. The two establish a physical connection via industrial Ethernet. Communication variable mapping is completed only through the configuration of the MCGS configuration panel, enabling the transmission of operating parameters from the PLC controller to the MCGS configuration panel. No changes are made to the underlying operating logic and control code of the PLC controller during the transmission process.

[0020] S2: Set differential trigger thresholds for each operating parameter and obtain the absolute change of the parameter. Determine the data reporting trigger status based on the comparison between the change and the threshold. This step is executed independently by the configuration display screen of the edge configuration layer. It is executed after each new set of valid operating parameters is acquired, and the execution scenario is the local processing stage of the edge configuration layer. Specifically, the configuration display screen locally stores all operating parameter values ​​that were successfully reported to the cloud last time. Each time a new valid parameter is received, the change in the current value of each parameter compared to the previously reported value is calculated. The configuration display screen pre-sets a corresponding change trigger threshold for each operating parameter. This threshold is the default baseline value under normal operating conditions of the shot blasting machine and can be flexibly adjusted according to the equipment model, process accuracy requirements, and on-site operating conditions. The actual change in each parameter is compared with the corresponding threshold one by one. If the change in any parameter reaches the trigger threshold, or if the equipment operating status indicator changes, a data report is triggered. If the change in the change of all parameters does not reach the threshold and the operating status remains unchanged, no report is triggered, and only the currently stored parameter values ​​are updated.

[0021] In this embodiment, it should be specifically noted that the differential trigger thresholds are set as follows: the MCGS configuration panel configures a differential trigger threshold for each operating parameter separately. Specifically, the differential trigger threshold for shot blasting current is 0.5A, the differential trigger threshold for shot blasting speed is 10r / min, the differential trigger threshold for shot level is 5mm, the differential trigger threshold for dust collector air pressure is 20Pa, and the differential trigger threshold for main motor temperature is 1... The equipment output differential trigger threshold is 1 piece, the cumulative runtime differential trigger threshold is 0.1 hours, and the equipment operation status code is a discrete enumeration quantity. No numerical differential trigger threshold is set; a change in the status code triggers an uploading. These thresholds are the default baseline values ​​under normal operating conditions of the shot blasting machine and can be adjusted according to the equipment model, process accuracy requirements, and on-site operating conditions. The method for obtaining the absolute change of parameters is as follows: the MCGS configuration screen caches the previously successfully reported parameter values, obtains the currently collected valid parameter values ​​in real time, and calculates the absolute change of each parameter by taking the absolute value of the difference. The calculation formula is... In the formula, , , , , , , , For input quantities, the values ​​represent, in order, the shot blaster current, shot blaster speed, shot material level, dust collector air pressure, main motor temperature, equipment operating status code, equipment output, and cumulative running time of the last successfully reported shot blaster. , , , , , , , The input values ​​are, in order, the currently collected shot blaster current, shot blaster speed, shot material level, dust collector air pressure, main motor temperature, equipment operating status code, equipment output, and cumulative running time. , , , , , , , The output quantities sequentially represent the absolute changes in shot blasting current, shot blasting speed, shot level, dust collector air pressure, main motor temperature, equipment operating status code, equipment output, and cumulative running time. The method for determining the trigger state of the data reporting is as follows: when the absolute change of any parameter is greater than or equal to its corresponding differential trigger threshold, or when the absolute change of the equipment operating status code is not 0, a data reporting is triggered; otherwise, no reporting is triggered, and only the current parameter value in the local cache is updated.

[0022] As attached Figure 2 As shown, S3: The heartbeat keep-alive cycle is dynamically adjusted based on the idle time without continuous reporting, and a data transmission mechanism is constructed by combining a simplified message format that only transmits changing parameters. This step is executed by the configuration display screen of the edge configuration layer. It is executed during the entire data transmission cycle, covering the data reporting stage and the idle standby stage. The execution scenario is local to the edge configuration layer, and the output data is sent to the cloud via the network transmission layer. The specific implementation process is as follows: The configuration display screen defines the duration of continuous non-triggered data reporting as the idle time, and dynamically adjusts the heartbeat keep-alive message sending interval according to the idle time. The longer the idle time, the longer the heartbeat sending interval. At the same time, upper and lower limits of the heartbeat interval are set to avoid wasting traffic due to too short an interval or causing connection disconnection due to too long an interval. Once data reporting is triggered, the idle time is immediately cleared to zero, and the heartbeat sending interval is restored to the initial default value. Data reporting adopts a simplified message format, which only includes the device's unique identifier, data timestamp, and changed parameter items and their corresponding values. Unchanged parameters are not included in the message content. Message sending adopts a service quality level of at least one delivery to ensure transmission reliability. The final total transmission traffic consists of data packet traffic and heartbeat message traffic. The monthly traffic of a single device is calculated according to the standard natural month, and the traffic is maintained at a low level through a combination of differential triggering and adaptive heartbeat control.

[0023] In this embodiment, it should be specifically noted that the dynamic adjustment method of the heartbeat keep-alive cycle is as follows: Define the idle duration without continuous trigger reporting and the heartbeat cycle parameter. The MCGS configuration panel linearly adjusts the heartbeat cycle based on the idle duration and sets upper and lower limit constraints. The adjustment formula is as follows: In the formula, The input value represents the idle time during which no trigger reporting occurs continuously, in seconds. is the input value representing the initial heartbeat cycle, with a value of 30s; k is the input value representing the heartbeat step size coefficient, with a value of 0.02, in units of s / s; This is the input value, representing the upper limit of the heartbeat cycle, with a value of 120 seconds. The input value represents the lower limit of the heart rate cycle, with a value of 30 seconds. The output represents the adjusted heartbeat period in seconds. The dynamic adjustment of the heartbeat period follows the principle of prioritizing connection reliability and secondarily optimizing traffic. The heartbeat period increases linearly with increasing idle time until it reaches its upper limit. The upper limit of the heartbeat period is set to 120 seconds, conforming to the common configuration of industrial IoT NAT session timeouts typically not less than 300 seconds, reserving sufficient margin to ensure connection activity. When data reporting is triggered, the idle time is reset to zero, and the heartbeat period returns to its initial value. The simplified message format for transmitting only changed parameters is as follows: the message content only includes the device's unique identifier, data timestamp, the identifier of the changed parameter, and its corresponding value. Unchanged parameters are not included in the message. Message publishing adopts QoS1 service quality level. The traffic calculation method for the data transmission mechanism is as follows: the application layer transmission rate is obtained by summing the data packet traffic and heartbeat packet traffic separately, and then converted to a standard natural month to obtain the monthly traffic per device. The application layer data transmission rate is calculated as follows: In the formula, f is the input quantity, representing the average data reporting frequency, in times / second; L is the input quantity, representing the effective payload length of a single data report, in bytes; This is an input value, representing the fixed header length of the Message Queue Telemetry Transport Protocol, with a value of 20 bytes. The input value represents the total length of a single heartbeat message, and its value is 32 bytes. B is the input, representing the heartbeat cycle in seconds; B is the output, representing the data transmission rate of the message queue telemetry transmission protocol application layer in bytes per second; the formula for calculating monthly traffic per device is... In the formula, B is the input, representing the application layer data transmission rate in bytes per second; M is the output, representing the monthly traffic of a single device in MB; the calculation is based on a standard 30-day calendar month.

[0024] S4: In the event of a network outage, data to be transmitted is temporarily stored in a local ring buffer unit. After the network is restored, the data is retransmitted in ascending order of timestamp and data deduplication is performed in the cloud. This step is jointly executed by the configuration display screen of the edge configuration layer and the message broker of the cloud service layer. It is executed during the network disconnection period and the retransmission phase after the network is restored. The execution scenarios are the edge local caching stage and the cloud access stage, respectively. The specific implementation process is as follows: The configuration display screen detects the network connection status through the cloud response status of heartbeat messages. When no response is received from the cloud after three consecutive heartbeat messages, it is determined that the network is disconnected. During the network disconnection, all data triggered for reporting and heartbeat messages are written to the configuration display screen's built-in local circular cache unit in chronological order. The cache unit has a fixed storage capacity, corresponding to the maximum temporary storage time under a fixed collection cycle. When the cache is full, new data automatically overwrites the oldest historical data to ensure that the cache always stores the latest running data. After the network is restored and the cloud connection is rebuilt, the configuration display screen retransmits the historical data in the cache to the cloud in chronological order from earliest to latest. The retransmission rate is set to a fixed value to avoid sudden large traffic surges impacting the network link. After receiving the retransmitted data, the cloud message broker performs deduplication based on the device's unique identifier and data timestamp. Only the first data record of the same device with the same timestamp is retained, and subsequent duplicate records are discarded to ensure the integrity and temporal consistency of data in short-term network outage scenarios.

[0025] In this embodiment, it is specifically noted that the local ring buffer unit temporarily stores data to be transmitted in the following way: the MCGS configuration screen has a built-in local ring buffer unit with a buffer capacity of 10,000 data records. Each record contains a timestamp and a complete reported data frame. This capacity corresponds to a maximum temporary storage time of approximately 16 minutes under a 100ms acquisition cycle. The network connection status is detected by heartbeat response. If no response is received from the cloud after three consecutive heartbeat messages based on the initial heartbeat cycle, it is determined that the network is disconnected. During the network disconnection period, all data triggered for reporting and heartbeat messages are written to the local ring buffer unit in the order of timestamps. When the local ring buffer unit is full, the new data overwrites the oldest historical data to ensure that the local ring buffer unit always stores the latest running data. The method of retransmitting data in ascending order by timestamp is as follows: After the network is restored and the message queue telemetry transmission protocol connection is rebuilt, the MCGS configuration screen retransmits the historical data in the local ring buffer unit to the cloud in ascending order of timestamp. The retransmission rate is set to 50 records / second. The retransmission is a short-term synchronization operation after the network is restored. This rate can complete the synchronization of cached data in a short time. The duration is short and will not have a significant impact on the overall monthly traffic index, which does not conflict with the normal low traffic design goal. The method of data deduplication is as follows: When the cloud EMQX message broker receives the retransmitted data, it performs deduplication based on the device's unique identifier and the data timestamp. For data records of the same device with the same timestamp, only the first received record is retained, and subsequent duplicate records are discarded.

[0026] S5: Adopts a three-tier architecture to build a multi-tenant data security protection system, which is suitable for two-tier tenant application scenarios; This step is jointly executed by the message broker, time-series database, and multi-tenant management module of the cloud service layer. It is executed during the entire process of data upload, storage, and query, and the execution scenario is the cloud service layer. The specific implementation process is as follows: The protection system adopts a three-layer isolation architecture, which is stacked sequentially from the transport layer to the storage layer and then to the application layer, adapting to the dual-layer application scenario of manufacturer super tenants and end-customer sub-tenants. The first layer is topic permission isolation. The message broker adopts a layered topic path design, with each tenant corresponding to a unique exclusive topic path. The multi-tenant management module assigns independent topic subscription and publishing permissions to each tenant. Tenants can only access topic data under their own exclusive path and cannot access data of other tenants across tenants. The second layer is database row-level isolation. The runtime data storage adopts a time-series database. Each data record is associated with the identity identifier of the corresponding tenant. All data query interfaces forcibly verify the tenant identity of the requester and only return data records that match the identity of the requesting tenant, thus achieving logical isolation of data from the storage layer. The third layer is data content anonymization. For end-customer sub-tenants, sensitive parameters such as equipment output and cumulative runtime are overlaid with fixed offsets exclusive to each tenant before being displayed externally. Manufacturer super tenants have full access to the original data, while end-customer sub-tenants can only access the anonymized data.

[0027] In this embodiment, the following details need to be explained: The three-layer architecture includes topic permission isolation, database row-level isolation, and data content anonymization; the implementation of topic permission isolation is as follows: the EMQX message broker adopts a layered topic design, with the topic format being tenant / {tenant unique identifier} / device / {device unique identifier} / data, where the tenant unique identifier is the tenant's unique identification code, and the device unique identifier is the device's unique identification code. The multi-tenant management module assigns independent topic subscription and publishing permissions to each tenant, and tenants can only access the topic data corresponding to their own tenant unique identifier and cannot access it across tenants; the implementation of database row-level isolation is as follows: the runtime data storage uses the TDengine time-series database, and each data record is associated with the corresponding tenant unique identifier field. All data query interfaces forcibly verify the tenant unique identifier parameter and only return data records that match the requested tenant unique identifier; the implementation of data content anonymization is as follows: for terminal customer sub-tenants, two sensitive parameters, device output and cumulative runtime, are anonymized with a fixed offset, and the anonymization formula is: In the formula, The input value represents the original value of the sensitive parameter; This is an input value representing a fixed offset specific to each tenant; The output represents the value displayed externally after anonymization. The manufacturer super tenant has full access to the original data, while the end-customer sub-tenant can only access the anonymized data. The multi-tenant data security protection system is constructed by sequentially layering topic permission isolation, database row-level isolation, and data content anonymization from the transport layer to the storage layer and then to the application layer to form a three-layer protection architecture. The adaptation rules for the two-layer tenant application scenario are as follows: the system adapts to both manufacturer super tenants and end-customer sub-tenants, each corresponding to different data access permissions and data ranges.

[0028] S6: The cloud-based rule engine sorts all received data by type and performs time-series storage and alarm data forwarding operations respectively. This step is jointly executed by the rule engine module, time-series database, and operation and maintenance work order module of the cloud service layer. It is executed after the data arrives at the cloud message broker, and within the data processing stage of the cloud service layer. Specifically, the rule engine module receives all data forwarded by the message broker and categorizes it into two types based on data attributes and triggering conditions: device operating status data and abnormal alarm data. Device operating status data is directly written to the time-series database for long-term storage. The storage strategy is differentiated based on parameter change frequency: the two types of parameters with higher change frequencies are stored for one year, while the five types of parameters with lower change frequencies and the device operating status identifier are stored for three years. Abnormal data that meets the alarm triggering conditions is directly forwarded to the operation and maintenance work order module for subsequent alarm processing.

[0029] In this embodiment, the specific implementation of the type-based traffic splitting is as follows: the cloud-based rule engine module receives all data forwarded by the EMQX message agent and divides it into two categories based on the data's attributes and triggering conditions: device operating status data and abnormal alarm data. The specific rules for time-series storage are as follows: for device operating status data, it is directly written into the TDengine time-series database. The storage strategy is as follows: the storage period for three types of high-frequency change data, namely shot blaster current, shot blaster speed, and equipment output, is 1 year; the storage period for four types of low-frequency change data, namely shot material level, dust collector air pressure, main motor temperature, and cumulative running time, is 3 years; and the storage period for device operating status codes is 3 years. The specific rules for alarm data forwarding are as follows: for abnormal data that meets the alarm triggering conditions, it is forwarded to the maintenance work order module and enters the alarm processing flow.

[0030] S7: Triggers tiered alarms based on transmitted operational data and automatically generates maintenance work orders, building an operational management link from alarms to archiving.

[0031] This step is executed by the maintenance work order module of the cloud service layer. It is executed when abnormal alarm data meeting the specified conditions is detected, and the execution scenario involves the cloud service layer and the maintenance application terminal. The specific implementation process is as follows: The system pre-sets multiple alarm trigger conditions specific to the shot blasting machine, and classifies alarm levels into four levels, with different types of alarms corresponding to different hazard levels. After an alarm is triggered, the maintenance work order module automatically generates a standardized maintenance work order. The work order content includes the equipment's unique identifier, equipment geographical location, alarm type, alarm time, and recommended handling solution. Subsequently, work order information is pushed through corresponding channels according to the alarm level. The highest-level alarm is pushed to the maintenance manager via SMS, the next highest-level alarm is pushed to on-site maintenance personnel via a mobile app, and the two lower-level alarms are displayed through the web management terminal. Work order execution covers a closed-loop process of automatic dispatch, on-site handling, acceptance confirmation, and archiving statistics. After the work order is archived, the fault data is synchronously updated to the equipment health file, and the fault statistics results are periodically output to the product development department to provide data support for the optimized design of the shot blasting machine.

[0032] In this embodiment, it should be specifically explained that the specific rules for triggering the graded alarms are as follows: Preset alarm triggering conditions specific to the shot blasting machine include emergency stop alarm, motor overcurrent alarm, abnormal air pressure alarm, low material level alarm, and consumable lifespan expiration warning. Specifically, the motor overcurrent alarm triggering condition is that the shot blaster current is greater than 45A; the abnormal air pressure alarm triggering condition is that the dust collector air pressure is less than 800Pa or greater than 1500Pa; the low material level alarm triggering condition is that the shot level is less than 100mm; and the consumable lifespan expiration warning triggering condition is that the cumulative running time reaches the rated lifespan threshold of the corresponding consumable. The alarm levels are divided into four levels: emergency stop alarm and motor overcurrent alarm are emergency level; abnormal air pressure alarm is important level; low material level alarm is general level; and consumable lifespan expiration warning is... The alarm level is designated as "notification level." The maintenance work order generation method is as follows: after an alarm is triggered, the maintenance work order module automatically generates a maintenance work order. The work order content includes the device's unique identifier, device geographical location, alarm type, alarm time, and recommended handling solution. Work order information is pushed through corresponding channels according to the alarm level. Emergency alarms are pushed to the maintenance manager via SMS, important alarms are pushed to maintenance personnel via WeChat mini-program, and general and notification alarms are displayed through the web management terminal. The maintenance management link is constructed as follows: a closed-loop process of automatic work order dispatch, on-site handling, acceptance confirmation, and archiving statistics. After the work order is archived, fault data is synchronously updated to the device health file. Fault statistics results are periodically output to the product development department to support the product optimization design of the shot blasting machine.

[0033] In conclusion, the above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A low-traffic data transmission method for shot blasting machines based on the MQTT protocol, characterized in that, include: S1: Collect multiple operating parameters of the shot blasting machine and perform parameter validity verification on the edge configuration side, while establishing a data communication connection; S2: Set differential trigger thresholds for each operating parameter and obtain the absolute change of the parameter. Determine the data reporting trigger status based on the comparison between the change and the threshold. S3: Dynamically adjust the heartbeat keep-alive cycle based on the continuous idle time without reporting, and construct a data transmission mechanism by combining a simplified message format that only transmits changing parameters; S4: In the event of a network outage, data to be transmitted is temporarily stored in a local ring buffer unit. After the network is restored, the data is retransmitted in ascending order of timestamp and data deduplication is performed in the cloud. S5: Adopts a three-tier architecture to build a multi-tenant data security protection system, which is suitable for two-tier tenant application scenarios; S6: The cloud-based rule engine sorts all received data by type and performs time-series storage and alarm data forwarding operations respectively. S7: Triggers tiered alarms based on transmitted operational data and automatically generates maintenance work orders, building an operational management link from alarms to archiving.

2. The low-traffic data transmission method for shot blasting machines based on the MQTT protocol according to claim 1, characterized in that: The acquisition method for the multiple operating parameters is as follows: the PLC controller acquires the parameters in real time at a 100ms acquisition cycle, specifically including shot blaster current I, shot blaster speed n, shot material level h, dust collector air pressure P, main motor temperature T, equipment operating status code S, equipment output, and cumulative running time H. The parameter validity verification method is as follows: the MCGS configuration panel compares the received parameter values ​​with the corresponding physical ranges. Data exceeding the range is judged as abnormal values ​​and filtered out, while valid data is retained for subsequent processing. The data communication connection method is as follows: the field control device is the PLC controller, and the configuration device is the MCGS configuration panel. The two establish a physical connection through industrial Ethernet. Communication variable mapping is completed only through the configuration of the MCGS configuration panel, realizing the transmission of operating parameters from the PLC controller to the MCGS configuration panel. No changes are made to the underlying operating logic and control code of the PLC controller during the transmission process.

3. The low-traffic data transmission method for shot blasting machines based on the MQTT protocol according to claim 1, characterized in that: The differential trigger thresholds are set as follows: the MCGS configuration panel configures a differential trigger threshold for each operating parameter separately. Specifically, the differential trigger threshold for shot blasting current is 0.5A, the differential trigger threshold for shot blasting speed is 10r / min, the differential trigger threshold for shot level is 5mm, the differential trigger threshold for dust collector air pressure is 20Pa, and the differential trigger threshold for main motor temperature is 1... The equipment output differential trigger threshold is 1 unit, the cumulative runtime differential trigger threshold is 0.1 hours, and the equipment operation status code is a discrete enumeration quantity. No numerical differential trigger threshold is set. A change in the status code triggers a report. The method for determining the data reporting trigger status is as follows: when the absolute change of any parameter is greater than or equal to its corresponding differential trigger threshold, or when the absolute change of the equipment operation status code is not 0, a data report is triggered. Otherwise, no report is triggered, and only the current parameter value in the local cache is updated.

4. The low-traffic data transmission method for shot blasting machines based on the MQTT protocol according to claim 1, characterized in that: The dynamic adjustment method for the heartbeat keep-alive cycle is as follows: Define the idle duration without continuous trigger reporting and the heartbeat cycle parameter. The MCGS configuration panel linearly adjusts the heartbeat cycle based on the idle duration and sets upper and lower limits. The adjustment formula is as follows: In the formula, This is the input value, representing the duration of continuous idle time without triggering a report; is the input value, representing the initial heartbeat cycle; k is the input value, representing the heartbeat step size coefficient; The input value represents the upper limit of the heartbeat cycle. The input value represents the lower limit of the heart rate cycle. The output represents the adjusted heartbeat cycle. The dynamic adjustment of the heartbeat cycle follows the principle of prioritizing connection reliability and secondarily optimizing traffic. As the idle time increases, the heartbeat cycle increases linearly until it reaches the upper limit. The upper limit of the heartbeat cycle is set to 120s, which conforms to the general configuration that the timeout of NAT sessions in industrial IoT is usually not less than 300s, reserving sufficient margin to ensure connection activity; when data reporting is triggered, the idle time is cleared to zero, and the heartbeat cycle is restored to the initial value; the simplified message format for transmitting only changed parameters is as follows: the message content only includes the device's unique identifier, data timestamp, the identifier of the changed parameter and its corresponding value, and the parameters that have not changed are not included in the message, and the message publication adopts the QoS1 service quality level.

5. The low-traffic data transmission method for shot blasting machines based on the MQTT protocol according to claim 4, characterized in that: The data transmission mechanism calculates traffic as follows: Data packet traffic and heartbeat packet traffic are calculated separately and then summed to obtain the application layer transmission rate. This is then converted to a standard natural month to obtain the monthly traffic per device. The application layer data transmission rate is calculated as follows: In the formula, f is the input quantity, representing the average data reporting frequency; L is the input quantity, representing the effective payload length of a single data report; This is an input value representing the fixed header length of the Message Queue Telemetry Transport Protocol (MQTP). The input value represents the total length of a single heartbeat message; B is the input, representing the heartbeat cycle; B is the output, representing the data transmission rate of the application layer of the message queue telemetry transport protocol.

6. The low-traffic data transmission method for shot blasting machines based on the MQTT protocol according to claim 1, characterized in that: The local ring buffer unit temporarily stores data to be transmitted in the following way: the MCGS configuration screen has a built-in local ring buffer unit with a buffer capacity of 10,000 data records. Each record contains a timestamp and a complete reported data frame. This capacity corresponds to a maximum temporary storage time of about 16 minutes under a 100ms acquisition cycle. The network connection status is detected by heartbeat response. If no response is received from the cloud after three consecutive heartbeat messages based on the initial heartbeat cycle, the network is considered disconnected. During the network disconnection period, all data and heartbeat messages that are triggered for reporting are written to the local circular buffer unit in chronological order according to their timestamps. When the local circular buffer unit is full, new data overwrites the oldest historical data to ensure that the local circular buffer unit always stores the latest running data. The method of supplementing data in ascending order of timestamps is as follows: after the network is restored and the message queue telemetry transmission protocol connection is re-established, the MCGS configuration screen supplements the historical data in the local circular buffer unit to the cloud in ascending order of timestamps, with the supplementation rate set to 50 messages / second. The method of data deduplication is as follows: when the cloud EMQX message broker receives the supplemented data, it performs deduplication based on the device's unique identifier and the data timestamp. For data records of the same device with the same timestamp, only the first received record is retained, and subsequent duplicate records are discarded.

7. The low-traffic data transmission method for shot blasting machines based on the MQTT protocol according to claim 1, characterized in that: The three-tier architecture includes topic permission isolation, database row-level isolation, and data content anonymization. The implementation of topic permission isolation is as follows: The EMQX message broker adopts a hierarchical topic design, with the topic format being tenant / {tenant unique identifier} / device / {device unique identifier} / data, where the tenant unique identifier is the tenant's unique identification code, and the device unique identifier is the device's unique identification code. The multi-tenant management module assigns independent topic subscription and publishing permissions to each tenant. Tenants can only access the topic data corresponding to their own tenant unique identifier and cannot access it across tenants. The implementation of database row-level isolation is as follows: Runtime data storage uses the TDengine time-series database. Each data record is associated with a corresponding tenant unique identifier field. All data query interfaces forcibly verify the tenant unique identifier parameter and only return data records that match the requested tenant unique identifier. The implementation of data content anonymization is as follows: For terminal customer sub-tenants, two sensitive parameters, equipment output and cumulative runtime, are anonymized using a fixed offset. The anonymization formula is: In the formula, The input value represents the original value of the sensitive parameter; This is an input value representing a fixed offset specific to each tenant; The output represents the value displayed externally after anonymization. The manufacturer super tenant has full access to the original data, while the end-customer sub-tenant can only access the anonymized data. The multi-tenant data security protection system is constructed by sequentially layering topic permission isolation, database row-level isolation, and data content anonymization from the transport layer to the storage layer and then to the application layer to form a three-layer protection architecture. The adaptation rules for the two-layer tenant application scenario are as follows: the system adapts to both manufacturer super tenants and end-customer sub-tenants, each corresponding to different data access permissions and data ranges.

8. The low-traffic data transmission method for shot blasting machines based on the MQTT protocol according to claim 1, characterized in that: The implementation of the type-based traffic splitting is as follows: The cloud-based rule engine module receives all data forwarded by the EMQX message agent and divides it into two categories based on the data's attributes and triggering conditions: equipment operating status data and abnormal alarm data. The specific rules for time-series storage are as follows: For equipment operating status data, it is directly written into the TDengine time-series database. The storage strategy is as follows: the storage period for three types of high-frequency changing data, namely shot blaster current, shot blaster speed, and equipment output, is 1 year; the storage period for four types of low-frequency changing data, namely shot material level, dust collector air pressure, main motor temperature, and cumulative running time, is 3 years; and the storage period for equipment operating status codes is 3 years. The specific rules for alarm data forwarding are as follows: For abnormal data that meets the alarm triggering conditions, it is forwarded to the maintenance work order module and enters the alarm processing flow.

9. The low-traffic data transmission method for shot blasting machines based on the MQTT protocol according to claim 1, characterized in that: The specific rules for triggering the graded alarms are as follows: Preset alarm trigger conditions specific to the shot blasting machine, including emergency stop alarm, motor overcurrent alarm, abnormal air pressure alarm, low material level alarm, and consumable lifespan expiration warning. Specifically, the motor overcurrent alarm trigger condition is that the shot blaster current is greater than 45A; the abnormal air pressure alarm trigger condition is that the dust collector air pressure is less than 800Pa or greater than 1500Pa; the low material level alarm trigger condition is that the shot level is less than 100mm; and the consumable lifespan expiration warning trigger condition is that the cumulative running time reaches the rated lifespan threshold of the corresponding consumable. The alarm levels are divided into four levels: emergency stop alarm and motor overcurrent alarm are emergency level; abnormal air pressure alarm is important level; low material level alarm is general level; and consumable lifespan expiration warning is reminder level. The maintenance work order generation method is as follows: after an alarm is triggered, the maintenance work order module automatically generates a maintenance work order. The work order content includes the unique identifier of the equipment, the geographical location of the equipment, the alarm type, the alarm time, and the recommended handling solution. The work order information is pushed to the corresponding channel according to the alarm level. Emergency alarms are pushed to the maintenance manager via SMS, important alarms are pushed to maintenance personnel via WeChat mini program, and general and warning alarms are displayed through the web management terminal. The maintenance management link is constructed as follows: the work order execution is a closed-loop process of automatic dispatch, on-site handling, acceptance confirmation, and archiving statistics. After the work order is archived, the fault data is synchronously updated to the equipment health file. The fault statistics results are periodically output to the product development department to support the product optimization design of the shot blasting machine.

Images