Industrial internet of things data pushing method and system

Abstract

This invention provides an industrial IoT data push method and system. The method includes acquiring target production data, which has corresponding target location identifiers and target gateway identifiers; determining target push task configuration information based on the target location identifiers and target gateway identifiers, which includes target push type and target push address; converting the target production data format based on the target push type to obtain a push message; and pushing the push message according to the target push address. This method can improve the data push flexibility and external system access capabilities of the industrial IoT platform.

Description

Technical Field

[0001] This invention relates to the field of industrial Internet of Things (IoT) technology, and in particular to an industrial IoT data push method and system. Background Technology

[0002] With the development of industrial IoT technology, industrial IoT platforms focus on pushing massive amounts of production data from industrial equipment to external systems in real time and reliably to enable applications such as production monitoring, quality traceability, and predictive maintenance.

[0003] Currently, mainstream data push solutions use a fixed data encapsulation method for unified forwarding of data collected from the same gateway. When faced with the diverse needs of different external systems, this solution suffers from problems such as inflexible configuration, coarse push granularity, and rigid data format conversion. It is difficult to adapt to different message formats, which limits the access capability of industrial IoT platforms in multi-system environments. Summary of the Invention

[0004] This invention provides an industrial Internet of Things (IoT) data push method and system to solve the technical problem that fixed data encapsulation push methods are difficult to adapt to different message formats when facing different external systems.

[0005] This invention provides an industrial Internet of Things (IoT) data push method, the method comprising: acquiring target production data, the target production data having corresponding target location identifier and target gateway identifier; determining target push task configuration information based on the target location identifier and the target gateway identifier, the target push task configuration information including target push type and target push address; converting the target production data in format based on the target push type to obtain a push message, and pushing the push message according to the target push address.

[0006] In one embodiment of the present invention, acquiring target production data includes: monitoring each message middleware, wherein each gateway uploads the collected production data to each of the message middleware; if the production data is detected, a message push request is initiated to a rate limiter so that the rate limiter can count the current message processing volume and generate a request pass message or a request reject message based on the current message processing volume; after receiving the request pass message returned by the rate limiter, the target production data is selected from the multiple detected production data.

[0007] In one embodiment of the present invention, the target push type includes a target message type and a target protocol type. Format conversion of the target production data includes: determining a corresponding target message construction strategy based on the target message type, and converting the target production data and target location metadata into a message body according to the target message construction strategy; wherein the target location metadata is obtained based on the target location identifier; determining a corresponding target protocol execution strategy based on the target protocol type, and converting the message body into the push message according to the target protocol execution strategy.

[0008] In one embodiment of the present invention, pushing the push message includes: matching the target protocol type and the target push address with each preset protocol type and each preset push address respectively, and determining the target circuit breaker from each circuit breaker according to the matching result; wherein, there is a corresponding relationship between the preset protocol type, the preset push address and the circuit breaker; and, under the condition that the target circuit breaker is in a normal state, pushing the push message according to the target push address.

[0009] In one embodiment of the present invention, after the push message is pushed, the method further includes: obtaining the current push result of the push message; under the condition that the current push result indicates that the push has failed, obtaining the current system time and counting the current retry count of the push message; calculating the next retry time based on the current system time and the current retry count, so as to re-push the push message according to the target push address at the next retry time.

[0010] In one embodiment of the present invention, the method further includes: counting the number of message push failures and the total number of message pushes on the push channel monitored by the circuit breaker according to a preset sliding time window, wherein the push channel is determined by a preset protocol type and a preset push address corresponding to the circuit breaker; calculating the push failure rate corresponding to the circuit breaker based on the number of message push failures and the total number of message pushes, and controlling the state of the circuit breaker based on the push failure rate.

[0011] In one embodiment of the present invention, controlling the state of the circuit breaker based on the push failure rate includes: setting the state of the circuit breaker to a closed state when the push failure rate is less than or equal to a preset failure rate threshold; setting the state of the circuit breaker to an open state when the push failure rate is greater than the preset failure rate threshold, and after the circuit breaker remains in the open state for a preset duration, setting the state of the circuit breaker to a half-open state; after setting the state of the circuit breaker to the half-open state, counting the number of consecutive successful message pushes on the push channel according to a preset sliding time window, and setting the state of the circuit breaker to a closed state when the number of consecutive successful message pushes reaches a preset success number threshold.

[0012] In one embodiment of the present invention, determining the target push task configuration information includes: matching the target location identifier and the target gateway identifier with the location identifier and gateway identifier in a mapping table, respectively, to obtain a target push task identifier; wherein, the mapping table is used to represent the mapping relationship between the location identifier, the gateway identifier, and the push task identifier; querying the corresponding historical push task configuration information from the historical cache space based on the target push task identifier, as the target push task configuration information; wherein, the historical cache space includes each of the historical push task configuration information and the corresponding push task identifier; if the query fails, reading the corresponding initial push task configuration information from the initial cache space based on the target push task identifier, as the target push task configuration information; wherein, the initial cache space includes each of the initial push task configuration information and the corresponding push task identifier; the data in the historical cache space is determined based on the data in the initial cache space, and the data volume of the historical cache space is less than or equal to the data volume of the initial cache space.

[0013] In one embodiment of the present invention, querying the corresponding historical push task configuration information from the historical cache space based on the target push task identifier includes: matching the target push task identifier with each cache key in the historical cache space; if a target cache key matching the target push task identifier exists, determining a target shard from multiple shards in the historical cache space based on the hash value corresponding to the target cache key; wherein each shard is used to cache multiple pieces of historical push task configuration information and corresponding push task identifiers; the cache key is determined based on multiple push task identifiers in the shard; the hash value corresponding to the cache key is used to identify the shard position where the historical push task configuration information and corresponding push task identifiers are cached; and reading the corresponding historical push task configuration information from the target shard based on the target push task identifier as the target push task configuration information.

[0014] This invention also provides an industrial IoT data push system, the system comprising: a data acquisition module for acquiring target production data, the target production data having corresponding target location identifiers and target gateway identifiers; a message push module for determining target push task configuration information based on the target location identifiers and the target gateway identifiers, the target push task configuration information including target push type and target push address; converting the target production data into a format based on the target push type to obtain a push message, and pushing the push message according to the target push address.

[0015] In one embodiment of the present invention, the data acquisition module includes: a consumer, configured to monitor each message middleware; if production data is detected, the consumer initiates a message push request to a rate limiter; and after receiving a request pass message returned by the rate limiter, the consumer selects the target production data from the monitored production data, wherein each gateway uploads the collected production data to each of the message middleware; and a rate limiter, configured to respond to the message push request, count the current message processing volume, and generate a request pass message or a request rejection message based on the current message processing volume.

[0016] In one embodiment of the present invention, the target push type includes a target message type and a target protocol type. The message push module includes: a message construction unit, configured to determine a corresponding target message construction strategy based on the target message type, and convert the target production data and target location metadata into a message body according to the target message construction strategy; wherein the target location metadata is obtained based on the target location identifier; and a protocol execution unit, configured to determine a corresponding target protocol execution strategy based on the target protocol type, and convert the message body into the push message according to the target protocol execution strategy; and to match the target protocol type and the target push address with each preset protocol type and each preset push address, respectively. The system is configured to: match and determine a target fuse from among the fuses based on the matching results; under the condition that the target fuse is in a normal state, push the message according to the target push address; wherein, there is a corresponding relationship between the preset protocol type, the preset push address, and the fuse; and a fuse protection unit is used to count the number of message push failures and the total number of message pushes on the push channel monitored by the fuse according to a preset sliding time window; calculate the push failure rate corresponding to the fuse based on the number of message push failures and the total number of message pushes, and control the state of the fuse based on the push failure rate; wherein, the push channel is determined by the preset protocol type and preset push address corresponding to the fuse.

[0017] The beneficial effects of this invention are as follows: The industrial IoT data push method and system proposed in this invention significantly improve the data push flexibility and external system access capability of the industrial IoT platform by introducing a dual identification mechanism of target point identifier and target gateway identifier, combined with dynamically matched push task configuration information. By configuring corresponding push types and push addresses according to different gateways and points, fine-grained differentiated routing and format conversion down to single gateways or even single points are achieved. When a new gateway is added, equipment is replaced, or different external systems are connected to the production site, only the push configuration of the corresponding point and gateway needs to be adjusted to achieve dynamic switching, effectively reducing operation and maintenance costs and response time. Attached Figure Description

[0018] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the invention and, together with the description, serve to explain the principles of the invention. It is obvious that the drawings described below are merely some embodiments of the invention, and those skilled in the art can obtain other drawings based on these drawings without any inventive effort.

[0019] In the attached diagram: Figure 1 This is a schematic diagram of the system architecture of an industrial Internet of Things (IoT) data push method according to an embodiment of the present invention; Figure 2 This is a flowchart illustrating an industrial Internet of Things (IoT) data push method according to an embodiment of the present invention. Figure 3 This is a block diagram of an industrial Internet of Things (IoT) data push system provided in an embodiment of the present invention; Figure 4 This is a schematic diagram of the message access layer provided in an exemplary embodiment of the present invention; Figure 5 This is a schematic diagram of the structure of a multi-protocol push engine provided in an exemplary embodiment of the present invention; Figure 6 This is an interactive schematic diagram of a multi-protocol push engine provided in an exemplary embodiment of the present invention; Figure 7 This is a schematic diagram of the workflow of an industrial Internet of Things (IoT) data push system provided by an exemplary embodiment of the present invention. Detailed Implementation

[0020] The following specific examples illustrate the implementation of the present invention. Those skilled in the art can easily understand other advantages and effects of the present invention from the content disclosed in this specification. The present invention can also be implemented or applied through other different specific embodiments. Various details in this specification can also be modified or changed based on different viewpoints and applications without departing from the spirit of the present invention. In the absence of conflict, the following embodiments and features in the embodiments can be combined with each other.

[0021] It should be noted that the illustrations provided in the following embodiments are only schematic representations of the basic concept of the present invention. The drawings only show the components related to the present invention and are not drawn according to the actual number, shape and size of the components in the actual implementation. In the actual implementation, the form, quantity and proportion of each component can be arbitrarily changed, and the layout of the components may also be more complex.

[0022] In the following description, numerous details are explored to provide a more thorough explanation of embodiments of the invention. However, it will be apparent to those skilled in the art that embodiments of the invention may be practiced without these specific details. In other embodiments, well-known structures and devices are shown in block diagram form rather than in detail to avoid obscuring embodiments of the invention.

[0023] It should be noted that with the development of Industrial Internet of Things (IIoT) technology and intelligent manufacturing, IIoT platforms need to push massive amounts of equipment production data to external systems in real time and reliably. However, current mainstream solutions each have limitations: First, direct API (Application Programming Interface) calls are simple to implement but have high coupling, prominent performance bottlenecks, and poor fault tolerance, easily leading to data loss or service avalanche. Second, while introducing a single message middleware for decoupling, it still faces problems such as single protocol support, excessive system complexity, tight coupling between push and consumption logic, and a lack of fine-grained flow control. Third, existing circuit breaker and caching mechanisms are insufficiently applied; circuit breaker granularity is coarse, and caching strategies are rigid, making it difficult to cope with high-concurrency scenarios. Therefore, the above mainstream solutions cannot meet the requirements of IIoT for multi-protocol adaptation, high throughput, high reliability, and high scalability.

[0024] To address these issues, embodiments of the present invention propose an industrial IoT data push method and an industrial IoT data push system, which will be described in detail below.

[0025] Please see Figure 1 , Figure 1 This is a schematic diagram of the system architecture of an industrial Internet of Things (IoT) data push method according to an embodiment of the present invention, as shown below. Figure 1As shown, the system architecture can include a gateway, message middleware, an industrial IoT data push system, and external systems. The gateway can be an industrial edge gateway, protocol conversion gateway, PLC (Programmable Logic Controller) acquisition gateway, intelligent data acquisition gateway, or IoT gateway, etc. The message middleware can be RocketMQ (Rocket Message Queue), Kafka (an open-source distributed messaging system), or other message middleware such as HTTP (Hypertext Transfer Protocol) or MQTT (Message Queuing Telemetry Transport). The industrial IoT data push system can be configured on the server side, which can be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server. The external system can be MES (Manufacturing Execution System), ERP (Enterprise Resource Planning System), or other third-party applications or systems; no restrictions are placed here. The gateway can collect production data from industrial equipment and upload it to the message middleware. The industrial IoT data push system obtains the target production data through the message middleware and pushes it to external systems.

[0026] In illustrative terms, the Industrial Internet of Things (IIoT) data push system acquires target production data, which has corresponding target location identifiers and target gateway identifiers. Based on these identifiers, it determines target push task configuration information, including target push type and target push address. The target production data is then format-converted based on the target push type to obtain a push message, which is then pushed according to the target push address. As can be seen, the technical solution of this invention significantly improves the data push flexibility and external system access capabilities of the IIoT platform by introducing a dual identifier mechanism of target location identifiers and target gateway identifiers, combined with dynamically matched push task configuration information. By configuring corresponding push types and push addresses according to different gateways and locations, it achieves fine-grained differentiated routing and format conversion down to single gateways or even single locations. When a new gateway is added to the production site, equipment is replaced, or different external systems are connected, only the push configuration of the corresponding location and gateway needs to be adjusted to achieve dynamic switching, effectively reducing operation and maintenance costs and response time.

[0027] Please see Figure 2 , Figure 2This is a flowchart illustrating an industrial IoT data push method according to an embodiment of the present invention. This industrial IoT data push method can be applied to... Figure 1 The system architecture shown is specifically implemented by the industrial IoT data push system within this system architecture. It should be understood that this industrial IoT data push method can also be applied to other exemplary system architectures and implemented by devices or systems in other system architectures. This embodiment does not limit the system architecture to which this industrial IoT data push method is applicable. Figure 2 As shown, in an exemplary embodiment, the industrial IoT data push method includes at least steps S210 to S230, which are described in detail below: Step S210: Obtain target production data.

[0028] Step S220: Determine the target push task configuration information based on the target location identifier and target gateway identifier corresponding to the target production data.

[0029] Step S230: Based on the target push type in the target push task configuration information, the target production data is format-converted to obtain a push message, and the push message is pushed according to the target push address in the target push task configuration information.

[0030] In step S210, the target production data refers to the production data currently being processed. There can be one, two, or more target production data points. Each target production data point has a corresponding target location identifier and a target gateway identifier. The location identifier indicates the data source of the production data, referring to the identification information of the collection point to which the production data belongs, used to uniquely determine which industrial equipment or specific sensor or measuring point on that industrial equipment the production data originates from. Correspondingly, the target location identifier refers to the identification information of the target collection point to which the target production data belongs. The gateway identifier refers to the identification information of the gateway that collects the production data; correspondingly, the target gateway identifier refers to the identification information of the target gateway that collects the target production data.

[0031] In step S220, the target push task configuration information includes the target push type and the target push address. The target push type refers to the message format and / or protocol type that the target production data needs to be converted into, which is used to determine how to perform the format conversion; the target push address refers to the network address of the target system receiving the target production data.

[0032] In some embodiments, information such as push type and push address can be pre-configured for each push task as push task configuration information; a mapping relationship between point identifier, gateway identifier and push task configuration information can be pre-established so that push task configuration information corresponding to both target point identifier and target gateway identifier can be determined based on target point identifier, target gateway identifier and mapping relationship, and used as target push task configuration information.

[0033] In other embodiments, information such as push type and push address can be pre-configured for each push task as push task configuration information, and corresponding identification information can be configured for each push task configuration information as push task identifier; a mapping relationship between point identifier, gateway identifier and push task identifier can be pre-established so that the target push task identifier corresponding to both the target point identifier and the target gateway identifier can be determined according to the target point identifier, the target gateway identifier and the mapping relationship, and the push task configuration information corresponding to the target push task identifier can be used as the target push task configuration information.

[0034] In step S230, the format conversion includes at least one of message format conversion and protocol format conversion.

[0035] In one embodiment of the present invention, step S210 includes: monitoring each message middleware, wherein each gateway uploads the collected production data to each message middleware; if production data is detected, a message push request is initiated to the rate limiter so that the rate limiter can count the current message processing volume and generate a request pass message or a request reject message based on the current message processing volume; after receiving the request pass message returned by the rate limiter, the target production data is selected from the multiple monitored production data.

[0036] In this embodiment, different types of consumers can consume production data collected by the gateway from the message middleware, enabling message consumption of various protocols such as HTTP, MQTT, Kafka, and RocketMQ.

[0037] A rate limiter can also be used to control the message consumption rate and prevent system overload. The current message processing volume can be the number of messages the system is currently processing per second. For example, a rate limit parameter can be set in a configuration file to define the maximum number of messages allowed to be processed per second. During system initialization, a rate limiter instance is created based on the configuration file; this rate limiter can be implemented using a token bucket algorithm. Before processing each message, the consumer initiates a message push request to the rate limiter, invoking the rate limiter's permission acquisition method. When the rate limiter determines that the current message processing volume does not exceed the upper limit indicated by the rate limit parameter, it grants permission to process the message and returns a request-approved message. When the rate limiter determines that the current message processing volume has reached the upper limit, it rejects the message processing request and returns a request-rejected message, thereby preventing system overload. The request-rejected message can indicate a system overload exception.

[0038] In some embodiments, different types of consumers can be dynamically enabled or disabled based on configuration. Specifically, consumer instances can be dynamically created through a conditional configuration mechanism by simultaneously enabling the corresponding data processing channel and specific protocol push functionality in the configuration file. Specific protocol push functionality can be dynamically enabled or disabled through conditional annotations, enabling configurable protocol plugin management.

[0039] In some embodiments, a processing mode can be selected from concurrent consumption, sequential consumption, and high-speed batch consumption modes based on the data volume and timing requirements of the production data, to select target production data from multiple production data according to the selected processing mode. For example, if there are timing requirements for the production data, a sequential consumption mode can be used to select target production data from multiple production data in chronological order. If there are no timing requirements for the production data, and the data volume exceeds a first threshold but does not exceed a second threshold, a concurrent consumption mode can be used to select target production data from multiple production data in parallel through multiple threads; if the data volume exceeds the second threshold, a high-speed batch consumption mode can be used to select target production data from multiple production data in parallel through multiple threads, with each thread selecting multiple target production data at a time. In concurrent consumption mode, a consumer can be declared as a listener for a message queue such as RocketMQ during initialization, specifying the topic to be listened to, the consumer group to which it belongs, and the consumption mode. Simultaneously, it is also registered as a listener for another message queue such as Kafka, forming a dual-consumption channel guarantee, and the number of concurrent consumption threads is specified through configuration items. The size of the consumer thread pool can be optimized based on a resource utilization formula to improve system resource utilization and processing capabilities. For example, the total number of threads in the thread pool is calculated as follows: Nthreads = N cpu · U cpu ·(1+ W / C Equation (1) in, N threads This represents the total number of threads in the thread pool. N cpu The number of CPU (Central Processing Unit) cores. U cpu For target CPU utilization, W For thread wait time, C Calculate the time for the thread.

[0040] In one embodiment of the present invention, step S220 includes: matching the target point identifier and the target gateway identifier with the point identifier and gateway identifier in the mapping relationship table, respectively, to obtain the target push task identifier; wherein, the mapping relationship table is used to represent the mapping relationship between the point identifier, the gateway identifier, and the push task identifier; querying the corresponding historical push task configuration information from the historical cache space based on the target push task identifier, as the target push task configuration information; wherein, the historical cache space includes each historical push task configuration information and the corresponding push task identifier; if the query fails, reading the corresponding initial push task configuration information from the initial cache space based on the target push task identifier, as the target push task configuration information; wherein, the initial cache space includes each initial push task configuration information and the corresponding push task identifier; the data in the historical cache space is determined based on the data in the initial cache space, and the data volume in the historical cache space is less than or equal to the data volume in the initial cache space.

[0041] Typically, the number of push tasks in an industrial IoT platform is large, possibly tens of thousands or thousands. The push task configuration information for each push task is usually stored in a database. Due to the large number of tasks, querying the target push task configuration information through the database can be quite slow.

[0042] In this embodiment, the push task configuration information in the database can be cached hierarchically to improve the matching efficiency of target push task configuration information. The hierarchical caching includes a first-level cache, a second-level cache, and a mapping cache. During the initialization phase, the system can read all push task configuration information and their corresponding push task identifiers from the database and cache them in the initial cache space as the initial push task configuration information and their corresponding push task identifiers; this is the first-level cache. Furthermore, it can read the mapping relationship between point identifiers, gateway identifiers, and push task identifiers from the database, form a mapping relationship table, and cache it in the mapping cache space; this is the mapping cache. During the runtime phase, the number of queries for each initial push task configuration information in the initial cache space can be counted according to a preset period. When the number of queries for the initial push task configuration information reaches a preset query threshold, the initial push task configuration information and its corresponding push task identifier are used as historical push task configuration information and their corresponding push task identifiers and cached in the historical cache space; this is the second-level cache.

[0043] The mapping cache maintains the mapping relationship between location identifiers, gateway identifiers, and sets of push task identifiers. Based on this mapping relationship, it allows for a reverse lookup of the target push task identifier that corresponds to both the target location identifier and the target gateway identifier. For example, the reverse lookup process can be formally defined as: given a location identifier, find the associated set of push task identifiers, which can be represented as follows: T ( a i )={t∣( a i , g j , t )∈ M for some g j ∈ G Equation (2) in, a i For the first i Point markers g j For the first j One gateway identifier, t To identify the push task, T ( a i ) for all with the first i Each location is identified by a corresponding push task identifier. M It is a set of mapping relationships formed by location identifiers, gateway identifiers, and push task identifiers. G This is a set of gateway identifiers.

[0044] In some embodiments, since the database typically stores a large amount of point metadata, the point metadata in the database can also be cached hierarchically to improve the query efficiency of the target point metadata. For example, during the initialization phase, the system can read all point metadata and their corresponding point identifiers from the database and cache them in the initial cache space as initial point metadata and their corresponding point identifiers; this is the first-level cache. During the runtime phase, the query count of each initial point metadata in the initial cache space can be counted at a preset period. When the query count of an initial point metadata reaches a preset query count threshold, the initial point metadata and its corresponding point identifier are then cached as historical point metadata and their corresponding point identifiers in the historical cache space; this is the second-level cache.

[0045] In some embodiments, the first-level cache can be based on a double-buffering cache structure, with a scheduled task periodically refreshing the database to update all data. During the refresh process, data is first loaded into a standby cache, and then an atomic reference switching operation is used to promote the standby cache to the current cache, achieving non-blocking data updates.

[0046] In some embodiments, the mapping table can also be updated and maintained. The mapping table can be updated synchronously when the database is refreshed, enabling efficient reverse lookup.

[0047] In one embodiment of the present invention, querying the corresponding historical push task configuration information from the historical cache space based on the target push task identifier includes: matching the target push task identifier with each cache key in the historical cache space; if a target cache key matching the target push task identifier exists, determining the target shard from multiple shards in the historical cache space based on the hash value corresponding to the target cache key; wherein each shard is used to cache multiple historical push task configuration information and the corresponding push task identifier; the cache key is determined based on the multiple push task identifiers in the shard; the hash value corresponding to the cache key is used to identify the shard position for caching the historical push task configuration information and the corresponding push task identifier; and reading the corresponding historical push task configuration information from the target shard based on the target push task identifier as the target push task configuration information.

[0048] In this embodiment, considering that the historical push task configuration information in the second-level cache may be large (i.e., the second-level cache may contain thousands or tens of thousands of data points), resulting in slow query efficiency, a sharded local cache design can be adopted for the second-level cache to improve query efficiency. The cache space corresponding to the second-level cache, i.e., the historical cache space, is divided into multiple independent shards. Each shard is configured with a maximum capacity limit and a time-based expiration policy, including both write-after-expiration and access-after-expiration mechanisms. The query parameters (i.e., the push task identifier) ​​are combined to form a cache key, and a hash operation is performed on the cache key to generate the corresponding hash value, ensuring the uniqueness of the query conditions.

[0049] For example, if several historical push task configuration information to be cached in a shard is cached in a shard, then the push task identifiers corresponding to these historical push task configuration information are concatenated into a string and used as the cache key; a hash calculation is performed on the concatenated string to generate a hash value; the remainder of the hash value and the total number of shards is taken to determine the shard position, i.e., the index, where the historical push task configuration information will be cached; the historical push task configuration information is stored in the corresponding shard according to the shard position, and a mapping relationship is formed between the cache key and the hash value for secondary caching, i.e., stored in the historical cache space.

[0050] When it is necessary to query or match the target push task configuration information, the string of the target push task identifier is matched with each cache key. If a cache key contains a string of a preset length that is the same as the string of the target push task identifier, it means that the target push task identifier belongs to that cache key. This cache key is then used as the target cache key. The hash value corresponding to the target cache key is then moduloed to determine the index of the target shard. Based on this index, the historical push task configuration information corresponding to the target push task identifier is retrieved from the target shard and used as the target push task configuration information.

[0051] For example, the index is calculated as follows: s = h ( k )mod N Equation (3) in, s For indexing, h () is a hash function. k For cache key, N is the total number of fragments, and mod is the modulo operator.

[0052] The sharded second-level cache for historical point metadata can also adopt the above method. That is, the point identifiers corresponding to several historical point metadata are concatenated into strings to form a cache key, and the corresponding hash value is calculated. The index is determined by taking the remainder of the hash value, and the historical point metadata is stored in the shard corresponding to the index. When it is necessary to query the metadata of a target point, the target cache key to which the target point identifier belongs is matched, and the index of the target shard is determined by taking the remainder of the hash value corresponding to the target cache key. Then, the historical point metadata corresponding to the target point identifier is read from the target shard according to this index, and used as the target point metadata.

[0053] Through the above design, while ensuring data matching, the original information of a large number of data points is compressed into a hash value, which can effectively save memory resources and improve the system query efficiency.

[0054] In one embodiment of the present invention, the target push type includes a target message type and a target protocol type. The target production data is format converted, including: determining the corresponding target message construction strategy based on the target message type, and converting the target production data and target location metadata into a message body according to the target message construction strategy; wherein the target location metadata is obtained by querying based on the target location identifier; determining the corresponding target protocol execution strategy based on the target protocol type, and converting the message body into a push message according to the target protocol execution strategy.

[0055] In this embodiment, during the system initialization phase, all message building strategy instances can be scanned and registered, and a strategy array can be created to store these instances. A quick index can be used to select the appropriate message building strategy by using the enumerated index of the strategy type (i.e., message type), thus implementing a message building strategy lookup mechanism. Based on the message building strategy, production data and location metadata are constructed into a data structure with a specified message format to meet the requirements of the target system (i.e., the target external system or the target receiver).

[0056] Protocol execution strategy instances for various push protocols, including HTTP, Kafka, MQTT, and RocketMQ, can be pre-built to quickly retrieve the corresponding execution strategy instance based on the enumeration sequence number of the protocol type. The protocol execution strategy can include the protocol data format; the system can select the appropriate protocol data format as the execution strategy based on the push task configuration information, and then convert the message body into a push message with the specified protocol data format using the execution strategy.

[0057] In one embodiment of the present invention, pushing a push message includes: matching the target protocol type and the target push address with each preset protocol type and each preset push address respectively, and determining the target circuit breaker from each circuit breaker according to the matching result; wherein, there is a corresponding relationship between the preset protocol type, the preset push address and the circuit breaker; and pushing the push message according to the target push address when the target circuit breaker is in a normal state.

[0058] In this embodiment, the target fuse is in a normal state including a closed or half-open state. The fuse state machine has three states: closed, open, and half-open. When the fuse state machine is in the open state, the corresponding fuse is in a blown state. When the fuse state machine is in the closed or half-open state, the corresponding fuse is in a normal state.

[0059] In some embodiments, the push task configuration information also includes authentication configuration information. After determining that the target circuit breaker is in a normal state, the system can select the corresponding authentication method according to the authentication configuration of the push task, generate authentication information, and send a request to the target system indicated by the target push address to push the message.

[0060] For example, you can first send an authentication request carrying authentication information to the target system for authentication, and then push a message to the target system after successful authentication. Alternatively, you can directly send a push message carrying authentication information to the target system.

[0061] For example, authentication methods include signature authentication and token authentication; for signature authentication, the system can use the current timestamp, random number and key to generate a digital signature for the request content; for token authentication, a pre-configured static token can be added directly to the request header.

[0062] In one embodiment of the present invention, after the push message is pushed, the method further includes: obtaining the current push result of the push message; if the current push result indicates that the push has failed, obtaining the current system time and counting the current number of retries for the push message; calculating the next retry time based on the current system time and the current number of retries, so as to re-push the push message according to the target push address at the next retry time.

[0063] For example, the calculation method for dynamically calculating the next retry time based on the current number of retries is as follows: t next = t current +2 r × f Equation (4) in, t next The time for the next retry. tcurrent The current system time. r This is the current number of retries. f This is the backoff factor, which can be preset.

[0064] After obtaining the next retry time, the push task is stored as a retry task in the priority queue for delayed retry. The priority of each retry task in the priority queue can be determined based on the corresponding next retry time.

[0065] In one embodiment of the present invention, the method further includes: counting the number of message push failures and the total number of message pushes on the push channel monitored by the circuit breaker according to a preset sliding time window, wherein the push channel is determined by a preset protocol type and a preset push address corresponding to the circuit breaker; calculating the push failure rate corresponding to the circuit breaker based on the number of message push failures and the total number of message pushes, and controlling the state of the circuit breaker based on the push failure rate.

[0066] In one embodiment of the present invention, controlling the state of a circuit breaker based on the push failure rate includes: setting the circuit breaker to a closed state when the push failure rate is less than or equal to a preset failure rate threshold; setting the circuit breaker to an open state when the push failure rate is greater than the preset failure rate threshold, and setting the circuit breaker to a half-open state after the circuit breaker has been in the open state for a preset duration; after the circuit breaker is set to the half-open state, counting the number of consecutive successful message pushes on the push channel according to a preset sliding time window, and setting the circuit breaker to a closed state when the number of consecutive successful message pushes reaches a preset success count threshold.

[0067] In this embodiment, a circuit breaker instance can maintain an independent success / failure call state for each independent push target, and calculate the push failure rate within a sliding time window to control the circuit breaker's state. The push target corresponds to the protocol type and push address. For example, the push failure rate is calculated as follows: FR = F current / T current Equation (5) in, FR To reduce push failure rate, F current This refers to the number of failed calls, i.e., the number of times message push failed. T current This represents the total number of calls, i.e., the total number of message pushes.

[0068] When the push failure rate exceeds the preset failure rate threshold T hWhen the state changes from closed to open, after a waiting period... T w That is, after a preset duration, the system will switch from an open state to a half-open state; in the half-open state, if the number of consecutive successful calls is [not specified], [the system will continue to operate]. S current That is, the number of consecutive successful message pushes reaches a preset success threshold. S h Then it changes from the half-open state to the closed state.

[0069] In some embodiments, if a call fails or the number of failed calls reaches a preset failure threshold in the half-open state, the half-open state is switched to the open state.

[0070] In other embodiments, the number of trial requests allowed in the half-open state can be pre-configured. In the half-open state, if the number of calls reaches the number of trial requests and the number of consecutive successful calls does not reach the preset success number threshold, the half-open state is switched to the open state.

[0071] In some embodiments, when the circuit breaker is in a half-open state, the flow of probe requests can also be controlled based on the token bucket algorithm, with the token addition rate and bucket capacity being configurable to gradually restore service.

[0072] The industrial IoT data push methods of various embodiments of this invention achieve flexible expansion of protocol support, adapting to various industrial application scenarios and meeting the diverse needs of different business scenarios for message ordering, real-time performance, and formatting. Through multi-level caching, cache segmentation, and flow control, the system processing efficiency is improved, meeting the high-concurrency processing requirements of massive industrial IoT data. Circuit breaking mechanisms and exponential backoff retries enhance the system's fault tolerance, effectively preventing data loss and cascading failures. Furthermore, adding new protocol execution strategies or message construction strategies requires no changes to the core architecture, making the system highly scalable and maintainable.

[0073] Please see Figure 3 , Figure 3 This is a block diagram of an industrial Internet of Things (IoT) data push system according to an embodiment of the present invention. This system can be applied to... Figure 1 The system architecture shown can also be applied to other exemplary system architectures. This embodiment does not limit the system architecture to which this system is applicable.

[0074] like Figure 3 As shown, this exemplary industrial IoT data push system includes: Data acquisition module 310 is used to acquire target production data, which has corresponding target location identifiers and target gateway identifiers; The message push module 320 is used to determine the target push task configuration information based on the target location identifier and the target gateway identifier. The target push task configuration information includes the target push type and the target push address. Based on the target push type, the target production data is format-converted to obtain the push message, and the push message is pushed according to the target push address.

[0075] In one embodiment of the present invention, the data acquisition module 310 includes: Consumers listen to each message middleware. If they detect production data, they send a message push request to the rate limiter. After receiving a request pass message from the rate limiter, they select the target production data from the multiple detected production data. Each gateway uploads the collected production data to each message middleware. A rate limiter is used to respond to a message push request, count the current message processing volume, and generate a request to pass a message or a request to reject a message based on the current message processing volume.

[0076] In one embodiment of the present invention, the target push type includes a target message type and a target protocol type, and the message push module 320 includes: The message construction unit is used to determine the corresponding target message construction strategy based on the target message type, and to convert the target production data and target location metadata into a message body according to the target message construction strategy; wherein, the target location metadata is obtained based on the target location identifier. The protocol execution unit is used to determine the corresponding target protocol execution strategy based on the target protocol type, and convert the message body into a push message according to the target protocol execution strategy; match the target protocol type and target push address with each preset protocol type and each preset push address respectively, and determine the target circuit breaker from each circuit breaker according to the matching results; and push the push message according to the target push address when the target circuit breaker is in a normal state; wherein, there is a corresponding relationship between the preset protocol type, preset push address and circuit breaker. The circuit breaker protection unit is used to count the number of message push failures and the total number of message pushes on the push channel monitored by the circuit breaker according to a preset sliding time window; calculate the push failure rate corresponding to the circuit breaker based on the number of message push failures and the total number of message pushes, and control the state of the circuit breaker based on the push failure rate; wherein, the push channel is determined by the preset protocol type and preset push address corresponding to the circuit breaker.

[0077] In an exemplary embodiment, the industrial IoT data push system can be implemented using a microservices architecture, where each functional module or unit can be deployed and expanded as an independent service. Regarding the hardware environment, the system can be deployed on a server cluster, using multi-core processors and sufficient memory to support high-concurrency data processing and caching operations. Regarding the software environment, the operating system can be a Linux distribution; the runtime environment requires a Java Virtual Machine; and the dependent middleware can include RocketMQ message queue components and Redis distributed caching databases. In terms of configuration management, all system parameters, such as function switches, thread pool parameters, cache size, and circuit breaker thresholds, can be centrally managed through a unified configuration file.

[0078] In one exemplary embodiment, the data acquisition module 310 may be a message access layer, and the message push module 320 may be a multi-protocol push engine. The message access layer dynamically enables or disables different types of consumers according to the configuration to consume production data collected by the gateway from the message middleware; the multi-protocol push engine works in conjunction with the message access layer to convert the production data into push messages and push them to external systems according to the push task configuration information.

[0079] Please see Figure 4 , Figure 4 This is a schematic diagram of the message access layer provided in an exemplary embodiment of the present invention, as shown below. Figure 4 As shown, the message access layer includes: The dynamic assembly module is used to dynamically enable or disable specific types of consumers based on configuration conditions. The multi-protocol consumer group, including HTTP consumers, MQTT consumers, Kafka consumers, and RocketMQ consumers, is used to consume messages from at least one of the four protocols, HTTP, MQTT, Kafka, and RocketMQ, based on the enabling or disabling of the dynamic assembly module, in order to listen to each message middleware and select target production data from multiple monitored production data. The consumption mode module is used to select one of the following processing modes based on the amount of production data and timing requirements: concurrent mode (concurrent consumption mode), sequential mode (sequential consumption mode), and batch mode (high-speed batch consumption mode). A flow controller is used to control the message consumption rate through a rate limiter to prevent system overload. The message processing core is used to transmit target production data to the multi-protocol push engine.

[0080] The core of production data acquisition lies in consumer instances, which are dynamically created through a conditional configuration mechanism. The system only creates a corresponding consumer instance when both the relevant data processing channel and the specific protocol push function are enabled in the configuration file. Consumers can be declared as listeners for RocketMQ message queues during initialization, specifying the topic to listen to, the consumer group they belong to, and the consumption mode. Simultaneously, they are also registered as listeners for Kafka message queues, forming a dual-consumption channel guarantee, and the number of concurrent consumption threads is specified through configuration items.

[0081] In some embodiments, the message consumption rate is controlled by setting a rate limit parameter in a configuration file, defining the maximum number of messages allowed to be processed per second. During system initialization, a rate limiter instance is created based on the configuration file; this rate limiter can be implemented using a token bucket algorithm. Before processing each message, the consumer calls the rate limiter's permission acquisition method. When the system's processing capacity reaches its limit, new message processing requests are immediately rejected, and a system busy exception is returned, thus preventing system overload.

[0082] Please see Figure 5 , Figure 5 This is a schematic diagram of the structure of a multi-protocol push engine provided in an exemplary embodiment of the present invention, as shown below. Figure 5 As shown, the multi-protocol push engine includes: The message construction unit is used to dynamically select a message construction strategy based on the push task configuration information corresponding to the accessed production data, and convert the production data into a data structure of a specified format as the message body; The protocol execution unit is used to dynamically select the protocol execution strategy according to the push task configuration information corresponding to the accessed production data, convert the message body into a protocol data format to obtain the push message, and push it to the external system. The circuit breaker protection unit, integrated with the protocol execution unit, is used to automatically circuit break when the push failure rate is too high, preventing the fault from spreading.

[0083] The message construction unit comprises a strategy factory subunit, a multi-strategy processing subunit, and a multi-level caching subunit. The strategy factory subunit quickly retrieves the corresponding message construction strategy instance based on the enumerated sequence number of the strategy type. The multi-strategy processing subunit integrates various message construction strategies, such as push strategies by gateway, push strategies by location, and combined push strategies, to filter and encapsulate production data according to different push task configuration information, forming the message body. The multi-level caching subunit caches push task configuration information, location metadata, and the mapping relationship between push task identifiers, location identifiers, and gateway identifiers.

[0084] The multi-level cache sub-unit adopts a hierarchical architecture, including: the first-level cache is implemented based on a double buffering mechanism, which is used to store the full amount of push task configuration information and point metadata, and supports non-blocking refresh; the second-level cache is implemented based on a segmented cache, which is used to cache the high-frequency push task configuration information query results and point metadata query results, and it uses a hash segmentation algorithm to reduce lock contention.

[0085] The protocol execution unit comprises a protocol factory subunit, a multi-protocol execution subunit, and an exponential backoff retry subunit. The protocol factory subunit quickly retrieves the corresponding protocol execution strategy instance based on the enumerated sequence number of the protocol type. The multi-protocol execution subunit integrates protocol execution strategies for various push protocols such as HTTP, Kafka, MQTT, and RocketMQ. The exponential backoff retry subunit dynamically calculates the next retry time based on the current retries after a push failure and stores the retry task in a priority queue for delayed retries.

[0086] The circuit breaker protection unit includes a circuit breaker instance, a circuit breaker state machine, and a rate limiter. The circuit breaker instance maintains an independent success / failure call state for each individual push target and calculates the push failure rate within a sliding time window. The circuit breaker state machine has three states: closed, open, and half-open. When the push failure rate exceeds a preset failure rate threshold... T h When the state changes from closed to open, after a waiting period... T w That is, after a preset duration, the system changes from an open state to a half-open state. In the half-open state, if the number of consecutive successful calls is [not specified], [the system will continue to operate]. S current That is, the number of consecutive successful message pushes reaches a preset success threshold. S h If the call fails, the system transitions from a half-open state to a closed state. If the call fails, the system transitions from a half-open state to an open state. The rate limiter controls the traffic of probe requests in the half-open state based on the token bucket algorithm. It gradually restores service by adding tokens to the rate and bucket capacity.

[0087] It is clear that the rate limiter configured in the message access layer and the rate limiter configured in the multi-protocol push engine can be two different rate limiters.

[0088] The implementation of the message building unit includes the implementation of the strategy factory subunit and the specific configuration and use of the multi-level caching subunit.

[0089] For example, the implementation of the strategy factory subunit includes: during the system initialization phase, the strategy factory subunit automatically scans and registers all messages to build strategy instances, uses a strategy array to store message-built strategy instances, and uses the enumeration index of the strategy type for fast indexing, thus realizing a strategy lookup mechanism with constant time complexity.

[0090] For example, the specific configuration and use of multi-level cache sub-units include: Level 1 Cache: Implements a cache structure based on a double-buffering mechanism, periodically refreshing all data through a scheduled task. During the refresh process, data is first loaded into a backup cache area, and then an atomic reference switching operation promotes the backup cache to the current cache, achieving non-blocking data updates. Level 2 Cache: Adopts a sharded local cache design, dividing the cache space into multiple independent shards. Each shard is configured with a maximum capacity limit and a time-based expiration policy, including both write-after-expiration and access-after-expiration mechanisms. The cache key is generated by hashing the combination of query parameters, ensuring the uniqueness of the query conditions. Mapping Cache: Maintains a mapping table, including mappings between point identifiers and push task identifiers, gateway identifiers and push task identifiers, etc. The mapping table is updated synchronously during data refresh, achieving efficient reverse lookup.

[0091] The collaborative implementation of the protocol execution unit and the fuse protection unit includes the protocol execution process and the specific configuration and status management of the fuse.

[0092] For example, the protocol execution process includes: the protocol execution unit first selects the appropriate authentication method according to the authentication configuration of the push task. For signature authentication, a digital signature can be generated for the request content using the current timestamp, a random number, and a key; for token authentication, a pre-configured static token can be directly added to the request header.

[0093] For example, the specific configuration and state management of the circuit breaker include: creating an independent circuit breaker instance for each push target. The circuit breaker configuration includes a failure rate threshold, a sliding window size for counting requests, a waiting time after the circuit breaker is closed, and the number of probing requests allowed in the half-open state. Internally, the circuit breaker maintains three states: closed, open, and half-open, and automatically transitions between these states based on the call result. Before executing a push request, the circuit breaker state corresponding to the protocol type and push address is checked first; if it is in the open state, the request is directly rejected.

[0094] Please see Figure 6 , Figure 6 This is an interactive diagram of a multi-protocol push engine provided by an exemplary embodiment of the present invention, such as... Figure 6 As shown, the interaction flow of each unit in the multi-protocol push engine is as follows: The message access layer receives data collected by the gateway, i.e., production data, and transmits it to the message construction unit of the multi-protocol push engine; The message building unit filters out the list of tasks to be pushed by querying the multi-level cache sub-units based on the location identifier and gateway identifier of the collected data. It then queries the corresponding message building strategy based on the push task configuration information in the task list to build a push message body (referred to as message body) in a specified message format and provides it to the protocol execution unit. The protocol execution unit receives the message body and selects the corresponding protocol execution strategy according to its protocol type to convert the push message body into a push message in the specified protocol format. Before executing the push, the protocol execution unit calls the circuit breaker protection unit to check the status of the target circuit breaker. If it is in the circuit breaker state, the process is terminated. If the status is normal, the push is executed. The fuse protection unit updates the fuse status based on the push notification results; If the push fails and retry is allowed, the exponential backoff retry subunit takes over the subsequent retry process, records the push log, calculates the push latency, and completes the entire push process.

[0095] Please see Figure 7 , Figure 7 This is a schematic diagram of the workflow of an industrial IoT data push system provided by an exemplary embodiment of the present invention, as shown below. Figure 7 As shown, the workflow of the industrial IoT data push system includes the data access and message construction process, and the protocol execution and result processing process.

[0096] The data access and message construction process is as follows: S1. Receive data collected by the gateway: The gateway device uploads the collected production data to a specified topic in a message queue such as RocketMQ or Kafka; S2. Dynamically configure and enable consumers: Enable or disable the corresponding consumers through configuration files to listen to the message queue through the enabled consumer instances; S3. Traffic Control and Permission Request: After the consumer instance of the corresponding protocol listens to the production data, it first requests processing permission from the rate limiter. After obtaining permission, it passes the production data to the multi-protocol push engine for processing. S4. Parse and process messages: Parse the production data to obtain the point identifier and attribute identifier corresponding to the production data; S5, multi-level caching supports data query: query push task configuration information based on location identifier and gateway identifier. First, check if there is a cached result in the second-level cache. If the second-level cache is not hit, query the first-level cache to get the complete task list and write the result to the second-level cache. S6. Strategy Factory selects the construction strategy: The strategy factory sub-unit selects the corresponding message construction strategy based on the strategy type configured for the task in the push task configuration information. S7. Construct the push message body: Based on the selected message construction strategy, convert the raw data, which includes at least production data, into a message body in the message format required by the target system.

[0097] The protocol execution and result processing flow is as follows: S8. Protocol Factory Selects Execution Strategy: The protocol factory subunit selects the corresponding protocol execution strategy based on the protocol type configured for the push task in the push task configuration information, so as to convert the message body into a push message that conforms to the protocol data format. S9. Check the fuse status: Use the combination of protocol type and push address as the key to obtain the corresponding fuse instance to check the fuse status; S10. Perform data push: If the fuse is in normal condition, send a request to the target system with authentication information to push the message. S11. Update fuse status: If the push is successful, record the success log and update the fuse status; if the push fails, the system records the failure log and updates the fuse status. S12, Exponential backoff retry mechanism: When the push fails or the circuit breaker is in a circuit-broken state, the push task is retried with a delay using the exponential backoff algorithm according to the retry configuration strategy. S13. Log recording and monitoring metrics: Record push logs and analyze push latency.

[0098] Figure 6 and Figure 7 For specific details of the illustrated process, please refer to the descriptions in the foregoing embodiments; they will not be repeated here. This industrial IoT data push system achieves flexible expansion of protocol support, adapting to various industrial application scenarios and meeting the diverse needs of different business scenarios for message ordering, real-time performance, and formatting. Through multi-level caching, cache segmentation, and flow control, the system's processing efficiency is improved, meeting the high-concurrency processing requirements of massive amounts of industrial IoT data. Circuit breaking mechanisms and exponential backoff retries enhance the system's fault tolerance, effectively preventing data loss and cascading failures. Furthermore, adding new protocol execution strategies or message construction strategies requires no changes to the core architecture, making the system highly scalable and maintainable.

[0099] It should be noted that the system provided in the above embodiments and the industrial IoT data push method provided in the above embodiments belong to the same concept. The specific ways in which each module or unit performs operations have been described in detail in the method embodiments, and will not be repeated here. In practical applications, the system provided in the above embodiments can be assigned to different functional modules or units as needed, that is, the internal structure of the system can be divided into different functional modules or units to complete all or part of the functions described above, and this is not a limitation.

[0100] The above embodiments are merely illustrative of the principles and effects of the present invention and are not intended to limit the invention. Any person skilled in the art can modify or alter the above embodiments without departing from the spirit and scope of the present invention. Therefore, all equivalent modifications or alterations made by those skilled in the art without departing from the spirit and technical concept disclosed in the present invention should still be covered by the claims of the present invention.

Claims

1. An industrial Internet of Things (IoT) data push method, characterized in that, The method includes: Acquire target production data, wherein the target production data has corresponding target location identifiers and target gateway identifiers; Based on the target location identifier and the target gateway identifier, the target push task configuration information is determined, which includes the target push type and the target push address. Based on the target push type, the target production data is format-converted to obtain a push message, and the push message is pushed according to the target push address.

2. The industrial IoT data push method according to claim 1, characterized in that, Obtain target production data, including: Each message middleware is monitored, and each gateway uploads the collected production data to its respective message middleware. If the production data is detected, a message push request is sent to the rate limiter so that the rate limiter can count the current message processing volume and generate a request pass message or a request reject message based on the current message processing volume. After receiving the request pass message returned by the rate limiter, the target production data is selected from the multiple monitored production data.

3. The industrial IoT data push method according to claim 1, characterized in that, The target push type includes the target message type and the target protocol type. The target production data undergoes format conversion, including: Based on the target message type, a corresponding target message construction strategy is determined, and the target production data and target location metadata are converted into a message body according to the target message construction strategy; wherein, the target location metadata is obtained based on the target location identifier. Based on the target protocol type, a corresponding target protocol execution strategy is determined, and the message body is converted into the push message according to the target protocol execution strategy.

4. The industrial IoT data push method according to claim 3, characterized in that, Sending the push message includes: The target protocol type and the target push address are matched with each preset protocol type and each preset push address, respectively, and the target fuse is determined from each fuse based on the matching results; wherein, there is a corresponding relationship between the preset protocol type, the preset push address and the fuse; Under the condition that the target fuse is in normal condition, the push message is pushed to the target push address.

5. The industrial IoT data push method according to claim 4, characterized in that, After the push message is sent, the method further includes: Get the current push result of the push message; If the current push result indicates that the push has failed, obtain the current system time and count the current number of retries for the push message; Based on the current system time and the current number of retries, the next retry time is calculated, and the push message is re-pushed according to the target push address at the next retry time.

6. The industrial IoT data push method according to claim 4, characterized in that, The method further includes: The number of message push failures and the total number of message pushes on the push channel monitored by the circuit breaker are counted according to a preset sliding time window. The push channel is determined by the preset protocol type and preset push address corresponding to the circuit breaker. The push failure rate corresponding to the circuit breaker is calculated based on the number of message push failures and the total number of message pushes, and the state of the circuit breaker is controlled based on the push failure rate.

7. The industrial IoT data push method according to claim 6, characterized in that, Controlling the state of the fuse based on the push failure rate includes: Under the condition that the push failure rate is less than or equal to the preset failure rate threshold, the state of the fuse is set to the closed state; Under the condition that the push failure rate is greater than the preset failure rate threshold, the state of the fuse is set to the open state, and after the fuse has been in the open state for a preset time, the state of the fuse is set to the half-open state. After setting the fuse to a half-open state, the number of consecutive successful message pushes on the push channel is counted according to the preset sliding time window. When the number of consecutive successful message pushes reaches a preset success number threshold, the fuse is set to a closed state.

8. The industrial IoT data push method according to claim 1, characterized in that, Determine the target push task configuration information, including: The target location identifier and the target gateway identifier are matched with the location identifier and gateway identifier in the mapping table, respectively, to obtain the target push task identifier; wherein, the mapping table is used to represent the mapping relationship between the location identifier, the gateway identifier and the push task identifier; Based on the target push task identifier, the corresponding historical push task configuration information is queried from the historical cache space and used as the target push task configuration information; wherein, the historical cache space includes each of the historical push task configuration information and the corresponding push task identifier; If the query fails, the corresponding initial push task configuration information is read from the initial cache space based on the target push task identifier, and used as the target push task configuration information; wherein, the initial cache space includes each of the initial push task configuration information and the corresponding push task identifier; the data in the historical cache space is determined based on the data in the initial cache space, and the amount of data in the historical cache space is less than or equal to the amount of data in the initial cache space.

9. The industrial IoT data push method according to claim 8, characterized in that, Based on the target push task identifier, query the corresponding historical push task configuration information from the historical cache space, including: The target push task identifier is matched with each cache key in the historical cache space. If a target cache key matches the target push task identifier, the target shard is determined from multiple shards in the historical cache space based on the hash value corresponding to the target cache key. Each shard is used to cache multiple historical push task configuration information and corresponding push task identifiers. The cache key is determined based on multiple push task identifiers in the shard. The hash value corresponding to the cache key is used to identify the shard position where the historical push task configuration information and corresponding push task identifiers are cached. Based on the target push task identifier, the corresponding historical push task configuration information is read from the target segment and used as the target push task configuration information.

10. An industrial Internet of Things (IoT) data push system, characterized in that, The system includes: The data acquisition module is used to acquire target production data, which has corresponding target location identifiers and target gateway identifiers; The message push module is used to determine target push task configuration information based on the target location identifier and the target gateway identifier. The target push task configuration information includes target push type and target push address. Based on the target push type, the target production data is format-converted to obtain a push message, and the push message is pushed according to the target push address.

11. The industrial IoT data push system according to claim 10, characterized in that, The data acquisition module includes: Consumers are used to listen to each message middleware. If production data is detected, they send a message push request to the rate limiter. After receiving a request pass message from the rate limiter, they select the target production data from the multiple detected production data. Each gateway uploads the collected production data to each message middleware. A rate limiter is used to respond to the message push request, count the current message processing volume, and generate a request pass message or a request reject message based on the current message processing volume.

12. The industrial IoT data push system according to claim 10, characterized in that, The target push type includes the target message type and the target protocol type, and the message push module includes: A message construction unit is used to determine the corresponding target message construction strategy based on the target message type, and convert the target production data and target location metadata into a message body according to the target message construction strategy; wherein the target location metadata is obtained based on the target location identifier. The protocol execution unit is configured to determine the corresponding target protocol execution strategy based on the target protocol type, and convert the message body into the push message according to the target protocol execution strategy; match the target protocol type and the target push address with each preset protocol type and each preset push address respectively, and determine the target circuit breaker from each circuit breaker according to the matching results; and push the push message according to the target push address when the target circuit breaker is in a normal state; wherein, there is a corresponding relationship between the preset protocol type, the preset push address, and the circuit breaker; The circuit breaker protection unit is used to count the number of message push failures and the total number of message pushes on the push channel monitored by the circuit breaker according to a preset sliding time window; calculate the push failure rate corresponding to the circuit breaker based on the number of message push failures and the total number of message pushes, and control the state of the circuit breaker based on the push failure rate; wherein, the push channel is determined by the preset protocol type and preset push address corresponding to the circuit breaker.

Images