Distributed adapter dynamic management method based on device assignment list

Abstract

The application discloses a distributed adapter dynamic management method based on a device allocation list, which introduces a device allocation list that can be dynamically updated, and constructs a decoupled cooperation architecture by using a message middleware, in which a data processor coordinates allocation and a protocol adapter performs collection and analysis. In this way, the static binding relationship between the device and the processing node is broken, the device allocation can be flexibly adjusted according to the system load and the node state, the single-point failure risk is effectively avoided, and the scalability and load self-adaptive ability of the system are significantly improved.

Description

Technical Field

[0001] This application relates to the field of intelligent management, and more specifically, to a method for dynamic management of distributed adapters based on a device allocation list. Background Technology

[0002] With the rapid development and deepening application of IoT technology, the number of connected smart devices globally is growing exponentially. This massive influx of devices generates high-concurrency data streams, posing unprecedented challenges to the throughput, scalability, and stability of backend data processing systems. To effectively address this challenge, distribute data processing pressure, and improve the overall system capacity, a distributed adapter architecture for accessing and initially processing data from different sources and using different protocols has become a common solution in the industry. Building an efficient distributed adapter dynamic management solution is crucial for ensuring the stable operation of large-scale IoT systems.

[0003] However, many current distributed adapter management solutions still have significant design shortcomings. Most of these solutions rely on a static or pre-configured device allocation mechanism, meaning that the binding relationship between devices and protocol adapters / data processors is fixed once established. This rigid management approach directly leads to multiple technical problems. First, there is a serious risk of single point of failure. When a protocol adapter or data processor fails, all devices bound to it will immediately interrupt their data reporting path, causing partial system paralysis and severely impacting business continuity and data integrity. Second, system scalability is also limited. When faced with a surge in device access, the system cannot smoothly and dynamically distribute the load of new devices to newly expanded or less loaded nodes. Adjusting processing capacity often requires manual intervention, resulting in slow response and low efficiency, thus restricting the system's elastic scaling capabilities.

[0004] Therefore, an optimized method for dynamic management of distributed adapters based on device allocation lists is needed. Summary of the Invention

[0005] To address the aforementioned technical problems, this application is proposed. Embodiments of this application provide a distributed adapter dynamic management method based on a device allocation list. This method introduces a dynamically updatable device allocation list and utilizes message middleware to construct a decoupled collaborative architecture where data processors coordinate allocation and protocol adapters perform data acquisition and parsing. This approach breaks the static binding relationship between devices and processing nodes, enabling flexible adjustment of device allocation based on system load and node status. This effectively mitigates single-point-of-failure risks and significantly improves system scalability and load adaptability.

[0006] According to one aspect of this application, a method for dynamic management of distributed adapters based on a device allocation list is provided, comprising:

[0007] The data processor pushes device information, including the target processor ID, to the corresponding protocol adapter via message middleware based on the device allocation list.

[0008] The protocol adapter acquires the target device's raw data frames based on the device information and through the communication acquisition device;

[0009] The protocol adapter parses the original data frame to obtain the parsed data packet;

[0010] The protocol adapter sends the parsed data packet to the corresponding data processor based on the target processor ID and through a message middleware.

[0011] After receiving the parsed data packet, the data processor extracts business data from the parsed data packet and executes the required business logic to obtain business events.

[0012] Compared with existing technologies, this application provides a distributed adapter dynamic management method based on a device allocation list. It introduces a dynamically updatable device allocation list and utilizes message middleware to construct a decoupled collaborative architecture where data processors coordinate allocation and protocol adapters perform data acquisition and parsing. This approach breaks the static binding relationship between devices and processing nodes, allowing device allocation to be flexibly adjusted according to system load and node status. This effectively avoids single-point-of-failure risks and significantly improves system scalability and load adaptability. Attached Figure Description

[0013] The above and other objects, features, and advantages of this application will become more apparent from the more detailed description of the embodiments of this application in conjunction with the accompanying drawings. The drawings are provided to further illustrate the embodiments of this application and form part of the specification. They are used together with the embodiments of this application to explain this application and do not constitute a limitation thereof. In the drawings, the same reference numerals generally represent the same components or steps.

[0014] Figure 1 This is a flowchart of a distributed adapter dynamic management method based on a device allocation list according to an embodiment of this application;

[0015] Figure 2 This is a data flow architecture diagram of a distributed adapter dynamic management method based on a device allocation list according to an embodiment of this application. Detailed Implementation

[0016] Hereinafter, exemplary embodiments according to this application will be described in detail with reference to the accompanying drawings. Obviously, the described embodiments are merely some embodiments of this application, and not all embodiments of this application. It should be understood that this application is not limited to the exemplary embodiments described herein.

[0017] As indicated in this application and claims, unless the context clearly indicates otherwise, the words "a," "an," "an," and / or "the" are not specifically singular and may include plural forms. Generally speaking, the terms "comprising" and "including" only indicate the inclusion of explicitly identified steps and elements, which do not constitute an exclusive list, and the method or apparatus may also include other steps or elements.

[0018] While this application makes various references to certain modules of the systems according to embodiments of this application, any number of different modules can be used and run on user terminals and / or servers. The modules described are merely illustrative, and different aspects of the systems and methods may use different modules.

[0019] Flowcharts are used in this application to illustrate the operations performed by the system according to embodiments of this application. It should be understood that the preceding or following operations are not necessarily performed in exact order. Instead, various steps can be processed in reverse order or simultaneously as needed. Furthermore, other operations can be added to these processes, or one or more steps can be removed from them.

[0020] Hereinafter, exemplary embodiments according to this application will be described in detail with reference to the accompanying drawings. Obviously, the described embodiments are merely some embodiments of this application, and not all embodiments of this application. It should be understood that this application is not limited to the exemplary embodiments described herein.

[0021] The technical solution of this application proposes a method for dynamic management of distributed adapters based on a device allocation list. Figure 1 This is a flowchart of a distributed adapter dynamic management method based on a device allocation list according to an embodiment of this application. Figure 2 This is a data flow architecture diagram for a distributed adapter dynamic management method based on a device allocation list according to an embodiment of this application. Figure 1 and Figure 2As shown, the distributed adapter dynamic management method based on a device allocation list according to an embodiment of this application includes the following steps: S1, the data processor pushes device information containing the target processor ID to the corresponding protocol adapter through a message middleware according to the device allocation list; S2, the protocol adapter obtains the original data frame of the target device based on the device information and through a communication collector; S3, the protocol adapter parses the original data frame to obtain a parsed data packet; S4, the protocol adapter sends the parsed data packet to the corresponding data processor based on the target processor ID and through a message middleware; S5, after receiving the parsed data packet, the data processor extracts business data from the parsed data packet and executes the required business logic to obtain a business event.

[0022] Specifically, in S1, the data processor pushes device information containing the target processor ID to the corresponding protocol adapter via message middleware according to the device allocation list. That is, the system's high-level, dynamically calculated device allocation decisions are transformed into specific, executable instructions and precisely communicated to each distributed protocol adapter unit responsible for data acquisition and preliminary processing. Through this proactive and decoupled configuration push mechanism, the system can break the traditional static binding relationship between devices and processing nodes, thereby enabling flexible scheduling and dynamic migration of devices between different adapters. This lays a solid foundation for subsequent implementation of refined load balancing, transparent failover, and elastic system scaling, fundamentally solving the technical problems of high single-point failure risk and poor system scalability caused by fixed allocation strategies in existing technologies.

[0023] The device allocation list is the core data structure of the entire dynamic management method. It is a list dynamically maintained by the data processor, recording the one-to-one mapping between all devices in the current system and their assigned protocol adapters, serving as the authoritative basis for global scheduling. Each record in the device allocation list includes a mapping relationship between the device ID and the protocol adapter ID. Device information is a specific configuration instruction package generated by the data processor for each device, including the device ID, device type, and target processor ID. The message middleware is an independent system component, such as RabbitMQ, Kafka, or RocketMQ. It plays a crucial role in asynchronous communication and application decoupling between the data processor and the protocol adapter, ensuring that allocation instructions can be transmitted reliably and non-blockingly.

[0024] In practical implementation, the data processor first needs to dynamically build or update the device allocation list. Here, it should be understood that the original device allocation mechanism relies on a predefined or simply generated static mapping list that directly associates devices with protocol adapters. The core flaw of this design lies in its fixed allocation relationship's lack of awareness and adaptive capability regarding the dynamic operating state of the system. When some protocol adapters experience excessive load due to centralized data reporting from their carriers or resource constraints, the mechanism cannot automatically adjust its allocation strategy to migrate the load, easily causing local performance bottlenecks. Simultaneously, this mechanism is a passive response management approach, failing to utilize the periodic load patterns revealed by massive historical data and unable to proactively schedule foreseeable business surges. This results in significant lag in the system's response to load fluctuations, impacting overall processing efficiency and stability. To address these technical shortcomings, a predictive load balancing-based intelligent allocation mechanism is proposed. This mechanism introduces a data-driven prediction and optimization model to achieve dynamic and intelligent device allocation.

[0025] In the technical solution of this application, the construction of the device allocation list includes:

[0026] First, predictive component load is obtained by forecasting future load based on historical metrics of protocol adapters. Specifically, the data processor periodically collects and analyzes historical performance metrics (such as CPU utilization, memory usage, network I / O, etc.) of all protocol adapters in the system, and uses this historical data to predict their load in the next scheduling cycle, thus obtaining a predictive component load. This forecasting process aims to transform discrete, past data points into a continuous and forward-looking assessment of the load status of each component in the next scheduling cycle by analyzing historical performance metrics, thereby filtering out short-term random fluctuations and providing a stable and reliable decision-making basis for subsequent optimized allocation. The forecasting calculation process follows an exponentially weighted moving average model, the calculation logic of which is: using the actual comprehensive load index of the previous cycle and the load forecast value of the previous cycle as a weighted average to obtain a smoother and more trend-predictive load forecast value for the current cycle. This process is expressed by the formula:

[0027]

[0028] in, For the first The protocol adapter in the previous cycle The overall load index For the first The protocol adapter in the previous cycle The load forecast value, This is the balancing factor. In a specific example, the overall load metric is a weighted combination of the protocol adapter's performance metrics, including CPU utilization, memory usage, and network I / O.

[0029] Next, a constrained allocation optimization model is constructed and solved based on predictive component load, device processing weight, and the global device registry to obtain the optimal allocation matrix. That is, after obtaining the predictive component load of all protocol adapters, a constrained allocation optimization model is constructed and solved. In this process, the data processor abstracts the device allocation problem into a combinatorial optimization problem. Its core computational logic is: with the optimization objective of minimizing the overall variance of the final predicted load of all protocol adapters in the system after task allocation, and under the constraint that each device must be assigned to one protocol adapter, the optimal device allocation scheme that maximizes the overall load balance of the system is solved. Thus, the resulting optimal allocation matrix is ​​no longer an allocation based on experience or fixed rules, but rather a precise solution that maximizes the overall load balance of the system, obtained through rigorous mathematical calculations after comprehensively considering the future load baseline of each adapter and the processing overhead of each device. Specifically, the objective function and constraints of this optimization model are expressed by the following formula:

[0030]

[0031] in, For the first The load forecast value for each protocol adapter in the current period. For the first The processing weight of each device Let be the decision variable, where if the _i_i _j_i ... The device is assigned to the first Each protocol adapter, then It is 1 if it is true, otherwise it is 0.

[0032] The constraints are:

[0033]

[0034] Then, based on the optimal allocation matrix, the device allocation list is generated. It should be understood that the mathematical matrix generated in the previous step is an abstract calculation result, which must be transformed into specific instructions that can be recognized and executed by various components in the system. Thus, the optimal allocation matrix is ​​parsed and translated into a structured list containing clearly defined binding relationships between devices, protocol adapters, and data processors, and this list is then issued as authoritative instructions throughout the entire system. In this way, a smart device allocation list is finally generated and distributed. Once this list is published, it drives each protocol adapter to dynamically adjust the range of devices it is responsible for, implementing the intelligent scheduling scheme calculated through prediction and optimization in the first two steps in the actual system, thereby completing a complete and automated load balancing closed loop.

[0035] In summary, this system endows the entire distributed adapter system with self-awareness and predictive optimization capabilities. The system can automatically identify and predict upcoming load changes, adjust device allocation strategies in advance, effectively avoid performance bottlenecks caused by concentrated loads, and significantly improve the overall utilization of system resources and operational stability. This fundamentally solves the system scalability and stability challenges caused by the massive number of connected devices and uneven data traffic in large-scale IoT platforms.

[0036] Taking the scheme of this application as an example, assuming that after the system starts and initializes, there are data processor instances D1 and D2 and protocol adapter instances A1 and A2. Data processor D1, as the current management master node, executes the above-mentioned load prediction and allocation optimization calculation process and generates a device allocation list. This list indicates that device "Device-001" should be handled by protocol adapter A1, while its business data should ultimately be processed by data processor D2. Accordingly, data processor D1 will read the device type of "Device-001" (such as "JT / T 808") from its database or configuration center, and then construct a device profile with the following content: {Device ID: "Device-001", Device Type: "JT / T 808", Target Processor ID: "D2"}. Subsequently, D1 serializes this structured device profile (e.g., converts it to JSON or Protobuf format) and publishes it as a message to a topic named "config_channel_for_A1" in the message middleware. Since protocol adapter A1 subscribed to this topic upon startup, it was able to receive this message immediately, thus knowing that it needed to start data acquisition and processing of "Device-001" and route the parsed data packets to data processor D2.

[0037] Specifically, in step S2, the protocol adapter acquires the target device's raw data frames based on the device information and through the communication collector. That is, it transforms the abstract allocation task issued by the data processor into a specific data acquisition action. The core value of this step lies in completely decoupling the protocol adapter's responsibilities from the underlying physical communication: the protocol adapter focuses on "when" and "for which device" to acquire data, while the communication collector focuses on "how" to communicate with the device. This separation of concerns architecture allows the protocol adapter to uniformly manage devices from different communication protocols, greatly enhancing the system's flexibility and maintainability, and providing the technical foundation for large-scale, heterogeneous device access management.

[0038] In specific implementation, firstly, after receiving the device data, the device ID and target processor ID are extracted from the device data. In this step, the device ID is a unique identifier of the data source to be collected; the target processor ID specifies the destination for subsequent data processing. In a specific implementation example, when protocol adapter A1 receives the content as follows...

[0039] When receiving device information in JSON format, the A1's internal code will parse it and assign the string "Device-001" to a device named... The internal variable is then assigned the string "D2" to a variable named... Internal variables;

[0040] Next, to efficiently manage the set of devices it is responsible for and provide fast query capabilities for subsequent frequent operations, the protocol adapter stores the device ID and target processor ID in a local device cache. This cache serves as a real-time snapshot of the protocol adapter's current workload, enabling it to independently perform subsequent data acquisition scheduling without relying on external queries. In this process, it should be understood that the protocol adapter typically needs to manage hundreds or thousands of devices simultaneously. Storing this information in a fast-access local cache can significantly improve the performance of subsequent operations, avoiding the overhead of re-parsing messages or querying external storage for each operation. Specifically, the device ID extracted in the previous step is used as the key, and an object containing the target processor ID and other relevant information (such as device type) is used as the value, stored in a memory-based data structure (such as a hash table, dictionary, or more complex concurrency-safe data structure) within the adapter instance. In this step, the local device cache is a core state store within the protocol adapter used to maintain its current scope of work, providing near-instantaneous access to device information.

[0041] In a continuation of the above implementation example, after retrieving the relevant ID, protocol adapter A1 will cache it on its local device (a... (Object) updated to:

[0042]

[0043] After that, A1 remembered its responsibility for Device-001 in its internal state;

[0044] Subsequently, the protocol adapter initiates a data retrieval request to the communication collector based on the device ID in the local device cache. In other words, the protocol adapter's proactive outward communication request after completing internal preparations demonstrates its role as a data acquisition task scheduler. In this way, it delegates the specific execution of data acquisition to a dedicated communication collector, thereby separating business logic from underlying communication. In practice, this is typically triggered by a scheduler within the protocol adapter. This scheduler can retrieve one or more device IDs from the local device cache based on timed polling (e.g., sending a request to all devices in the cache every minute), event triggering, or other more complex strategies. The protocol adapter then constructs a clear data retrieval request directed to the communication collector service. This request is typically issued as an API call, passing the device ID as a core parameter. In this step, the data retrieval request is a programmatic instruction sent by the protocol adapter to the communication collector.

[0045] Continuing with the above implementation example, when the internal timer of protocol adapter A1 expires, it will traverse the local device cache, find the record "Device-001", and then call the interface exposed by the communication collector in the system, for example, by initiating an RPC call:

[0046]

[0047] Subsequently, after communicating with the target device, the communication collector returns the raw data frame to the protocol adapter. During this process, upon receiving the request, the communication collector handles all the low-level communication details with the target physical device. After successfully communicating with the target device and acquiring data, it returns the raw data frame, unparsed and unmodified, to the requesting protocol adapter. Specifically, upon receiving the pull request from the protocol adapter, the communication collector first queries its own configuration library based on the input device ID (e.g., "Device-001") to find all the parameters required for communication with the device (e.g., IP address, port, device address code, communication protocol type, etc.). Then, it uses these parameters to establish a connection with the target physical device and sends instructions to read data according to the corresponding communication protocol stack. When the communication collector receives the response data from the device, it returns this raw, unprocessed data frame as the return value of this request to the waiting protocol adapter. In this step, the raw data frame refers to the uninterpreted binary byte stream or text data directly obtained from the device, serving as the starting point for all subsequent data processing.

[0048] In the final stage of the implementation example, after receiving the request from A1, the communication collector communicated with the water meter "Device-001" via TCP / IP and successfully read a string of hexadecimal data. The communication collector then uses this complete byte array as... The return result of the call is sent back to protocol adapter A1. At this point, A1 has successfully completed a full data acquisition process for "Device-001".

[0049] Specifically, in step S3, the protocol adapter parses the original data frame to obtain the parsed data packet. It should be understood that in practical applications, devices from different manufacturers and models often use drastically different communication protocols and data formats (such as JT / T 808, Modbus, CJ / T 188, etc.). Therefore, the system must be able to flexibly adapt to multiple protocols. By dynamically selecting the appropriate parsing module based on the device type to parse the original data frame, the system ensures that it can correctly parse data from any known protocol, avoiding the problems of unscalability and maintenance difficulties caused by using a single, hard-coded logic.

[0050] In practice, the protocol adapter first calls the corresponding parsing module based on the device type. During this process, when the protocol adapter is ready to process a raw data frame acquired from the communication collector, it first searches for the corresponding device record in its internal local device cache based on the device ID associated with the data frame. From this record, the protocol adapter extracts the previously stored device type information. This device type field, as a unique identifier, is used as a key for searching in a pre-built parsing module registry. This registry maintains a mapping relationship from device type to specific parsing module instances. Once a matching parsing module instance is found, that instance is selected and prepared for subsequent data parsing. In this step, the parsing module is an independent software component (e.g., a class or a set of functions) that encapsulates all the parsing logic for a specific protocol. It is proficient in all the details of a specific protocol's message structure, encoding method, verification algorithm, etc. The registry is a data structure (such as a hash table or dictionary) held internally by the protocol adapter. It dynamically builds the association between device type and parsing module during system initialization or runtime, thereby achieving efficient lookup and matching between the two. In a specific implementation example, after obtaining the raw data frame of device "Device-001", protocol adapter A1 queries its local device cache and finds that the device type corresponding to "Device-001" is "JT / T 808". Subsequently, A1 accesses its internal parsing module registry, queries using "JT / T 808" as the key, and successfully obtains a pre-registered and instantiated device. This object is the parsing tool specifically adapted to process this raw data frame;

[0051] Furthermore, the original data frame is parsed based on the corresponding parsing module to obtain the parsed data packet. This is a crucial step in transforming the raw byte stream, which is meaningless to upper-layer applications, into a structured data packet containing clear business meaning. In this way, the raw data can be endowed with business-level semantics, and then used by the data processor for subsequent business logic judgments, data storage, and event generation. In specific implementation, the parsing module instance selected in the previous step is invoked, and the raw data frame to be processed is passed as an input parameter to the parsing module instance. Internally, this parsing module performs a series of rigorous parsing operations specific to the chosen protocol. These operations typically include: message verification, such as checking the start and end identifiers of the data frame for correctness, and calculating the message body according to the algorithm specified in the protocol (such as cyclic redundancy check, checksum, etc.), comparing the calculation result with the checksum appended to the end of the message to ensure that no errors occurred during data transmission; data decoding, where the parsing module extracts data fields one by one from the byte stream of the original data frame according to the field order and length specified in the protocol, and decodes them according to the data type (such as integer, floating-point, BCD code, string, etc.) and byte order (big-endian or little-endian) defined in the protocol, converting the binary data into numerical values ​​or strings for the program's internal use; and data structuring, where the parsing module encapsulates all the decoded business data and fills it into a predefined parsed data packet object. In this step, the parsed data packet is a structured data object (such as a JavaBean or a JSON object), which contains multiple key-value pairs with clear business meanings, making the data self-describing and easy to process by subsequent programs.

[0052] In a specific implementation example, the previously selected The object receives a raw data frame (a stream of hexadecimal bytes) from "Device-001". The parser first verifies the frame header. The system checks if the identifier and frame end checksum are correct. If verification is successful, it extracts four bytes representing the cumulative data usage from a specific location in the data frame, according to the JT / T 808 protocol specification, and decodes it from BCD format to the decimal number 1234.56. Then, it extracts one byte representing the battery level from another location and converts its value to a percentage of 90%. Finally, Create a new data packet object and populate it with the parsed data. The final parsed data packet might be a JSON object like the one shown below:

[0053]

[0054] This structured data packet, containing business meaning, is the parsed data packet.

[0055] Specifically, in step S4, the protocol adapter sends the parsed data packet to the corresponding data processor based on the target processor ID and via message middleware. It should be understood that in a distributed architecture, having a specific data processor handle a portion of the device's business logic helps achieve state management, data aggregation, and fault isolation. By using the target processor ID as the routing basis, it ensures that data originating from the same device is always sent to the designated processing node, thereby guaranteeing the continuity and consistency of business processing. Simultaneously, sending data via message middleware achieves asynchronous decoupling between the protocol adapter and the data processor, greatly improving the overall robustness, scalability, and maintainability of the system: the protocol adapter does not need to care about the data processor's network location, real-time status, or even its existence; it only needs to deliver the data packet to the message middleware, allowing each part of the system to scale, upgrade, or recover from faults independently.

[0056] The specific implementation process is a targeted transmission flow actively triggered by the protocol adapter after completing data parsing. First, to determine where the data packet should be sent, the protocol adapter needs to query and obtain the associated target processor ID from its internal local device cache based on the device ID in the currently parsed data packet. This ID is specified by the data processor when sending device information at the very beginning of this method and stored in the local cache by the protocol adapter after receiving the packet. Next, after obtaining the target processor ID, the protocol adapter dynamically constructs the message middleware target address for this communication according to a predefined system naming convention. This is usually the name of a specific topic or queue. For example, a common software engineering practice is to format the target address as "data_upload_channel_D2" followed by the target processor ID. Finally, the protocol adapter serializes the "parsed data packet" object in memory into a standard format suitable for network transmission (usually a byte stream in binary format such as JSON or Protobuf), and then calls its internally integrated message middleware client library to publish this serialized data as the message body to the target address constructed in the previous step. At this point, the protocol adapter's task in this data processing cycle is complete.

[0057] In this step, the target processor ID is a unique identifier for a data processor instance within the system, determining the final destination of the data packet. This ID is assigned based on dynamic allocation decisions made at a higher level within the system. The parsed data packet is a data object that has undergone the transformation from a raw byte stream to structured information; its content is transparent and usable to business logic.

[0058] Taking the solution of this application as an example, continuing the previous process, protocol adapter A1 has successfully parsed the raw data frame from device "Device-001" into a structured data packet, the content of which is:

[0059]

[0060] At this point, A1 will execute the following steps: First, A1 queries its internal local device cache using "Device-001" as the key, retrieving the previously stored target processor ID for this device as "D2". Then, according to the system's naming rules, protocol adapter A1 concatenates the target processor ID "D2" with the base channel name "data_upload_channel_" to construct the target topic name for this transmission: "data_upload_channel_D2". Finally, A1 serializes the aforementioned JSON data packet object into a UTF-8 encoded string and calls the message middleware's API to publish this message to the topic "data_upload_channel_D2". On the other end of the system, data processor D2, having subscribed to this topic upon startup, can immediately receive this message and begin executing subsequent business logic processing on its content.

[0061] Specifically, in step S5, after receiving the parsed data packet, the data processor extracts business data from the parsed data packet and executes the required business logic to obtain business events. That is, the structured data collected and parsed throughout the entire system is ultimately transformed into insights with practical business significance, persistent records, and actions that can drive external responses, thereby truly achieving the ultimate goal of effectively monitoring and managing massive amounts of device data.

[0062] Business data consists of atomic information with clear business meaning extracted from the payload of parsed data packets, such as specific temperature readings or pressure values; these are the direct operands for business logic processing. Business logic is a collection of business rules, algorithms, and processing flows encoded and implemented in the data processor, defining how the system should respond to different data inputs. A business event is a self-contained data record describing a meaningful event that occurred at the business level, such as a "low battery alarm event" or a "pipeline pressure anomaly event," enabling changes in the system's state to be perceived and responded to by other systems or personnel.

[0063] In practice, the data processor first continuously listens to a message middleware channel specifically configured for it (e.g., a topic or queue named after its own ID). Once a new message arrives at this channel, the data processor consumes it. Since the message body is the serialized and parsed data packet sent by the protocol adapter in the previous step, the data processor immediately uses a corresponding deserialization tool (such as a JSON parsing library) to restore the message from its network transmission format (such as a byte stream or string) into a structured, directly accessible parsed data packet object in memory. After successful deserialization, the data processor proceeds to the second sub-step: extracting business data. In this step, the data processor's program logic directly accesses the internal fields of the parsed data packet object in memory, especially delving into its core payload, extracting various data values ​​directly related to the specific business scenario, such as instantaneous traffic, cumulative traffic, pressure, temperature, and battery level. These values ​​are then assigned to internal business variables for subsequent logic processing. Next, the third sub-step begins: executing the required business logic. In this step, the data processor performs a series of calculations, analyses, and judgments on the extracted business data according to pre-configured business rules. The complexity of these business logics varies, ranging from simple threshold checks (e.g., checking if battery power is below a preset alarm threshold) to complex trend analysis and anomaly detection (e.g., comparing water consumption data with historical data from the same period to determine if there is an abnormal surge in current water consumption to detect potential pipe leaks), as well as routine data aggregation and statistics (e.g., calculating daily / monthly / yearly cumulative usage), and correlation queries between business data and other metadata of the device (such as user information). Finally, based on the execution result of the business logic, the data processor proceeds to the fourth sub-step: generating a business event. If the judgment result of the business logic triggers a predefined condition, the data processor instantiates a business event object, which encapsulates all relevant information for this event and publishes it to the system for consumption by other services or user interfaces. Simultaneously, as part of the business logic, the data processor typically also persists the processed business data to a database for historical queries and long-term analysis.

[0064] Taking the scheme of this application as an example, continuing the previous process, the data processor D2 receives a message on its dedicated data upload channel "data_upload_channel_D2". D2 first sends the JSON string of the message:

[0065]

[0066] The data is deserialized into an in-memory data object. D2 then extracts the business data from it: cumulative traffic is 1234.56, and battery level is 15. Next, D2 executes its internal business logic: first, it stores the device ID "Device-001", the current timestamp, the cumulative traffic of 1234.56, and the battery level of 15 as a record in the water supply network time-series database it manages. Then, it executes threshold judgment logic to check if the battery level of 15 is lower than the preset alarm threshold of 20%. Since 15 is less than 20, the condition is triggered. Therefore, D2 immediately generates a business event, which may be a JSON object with the following structure:

[0067]

[0068] This business event object will then be published to another message topic called "system_alerts" for the system's alarm service to subscribe to and process. After receiving this event, the alarm service may send a low battery alarm notification to the maintenance personnel responsible for the device via SMS or mobile app.

[0069] In summary, the distributed adapter dynamic management method based on a device allocation list according to the embodiments of this application is explained. It introduces a dynamically updatable device allocation list and utilizes message middleware to construct a decoupled collaborative architecture where data processors coordinate allocation and protocol adapters perform data acquisition and parsing. This approach breaks the static binding relationship between devices and processing nodes, allowing device allocation to be flexibly adjusted according to system load and node status, thereby effectively avoiding single-point-of-failure risks and significantly improving the system's scalability and load adaptability.

[0070] The various embodiments of this disclosure have been described above. These descriptions are exemplary and not exhaustive, nor are they limited to the disclosed embodiments. Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the described embodiments. The terminology used herein is chosen to best explain the principles, practical application, or improvement of the technology in the market, or to enable others skilled in the art to understand the embodiments disclosed herein.

Claims

1. A method for dynamic management of distributed adapters based on a device allocation list, characterized in that, include: The data processor pushes device information, including the target processor ID, to the corresponding protocol adapter via message middleware based on the device allocation list. The protocol adapter acquires the target device's raw data frames based on the device information and through the communication acquisition device; The protocol adapter parses the original data frame to obtain the parsed data packet; The protocol adapter sends the parsed data packet to the corresponding data processor based on the target processor ID and through a message middleware. After receiving the parsed data packet, the data processor extracts business data from the parsed data packet and executes the required business logic to obtain business events; The process of dynamically updating the device allocation list includes the following steps: predicting future loads based on historical metrics of protocol adapters to obtain predictive component loads; constructing and solving a constrained allocation optimization model based on predictive component loads, device processing weights, and a global device registry to obtain an optimal allocation matrix; and generating the device allocation list based on the optimal allocation matrix. The constrained allocation optimization model is expressed as follows: ， in, For the first The load forecast value for each protocol adapter in the current period. For the first The processing weight of each device Let be the decision variable, where if the _i_i = _i ... The device is assigned to the first Each protocol adapter, then It is 1 if it is true, otherwise it is 0. The constraints are as follows: ， in, These are decision variables.

2. The method for dynamic management of distributed adapters based on a device allocation list according to claim 1, characterized in that, Each record in the device allocation list includes a mapping relationship between the device ID and the protocol adapter ID.

3. The distributed adapter dynamic management method based on a device allocation list according to claim 2, characterized in that, The device information includes the device ID, device type, and target processor ID.

4. The method for dynamic management of distributed adapters based on a device allocation list according to claim 1, characterized in that, The protocol adapter acquires the target device's raw data frames based on the device information and through the communication collector, including: After receiving the device information, extract the device ID and target processor ID from the device information; Store the device ID and target processor ID in the local device cache; The protocol adapter initiates a data retrieval request to the communication collector based on the device ID in the local device cache; After communicating with the target device, the communication acquisition unit returns the raw data frames to the protocol adapter.

5. The method for dynamic management of distributed adapters based on a device allocation list according to claim 1, characterized in that, The protocol adapter parses the original data frame to obtain parsed data packets, including: The protocol adapter calls the corresponding parsing module based on the device type; The original data frame is parsed using the corresponding parsing module to obtain the parsed data packet.

6. The method for dynamic management of distributed adapters based on a device allocation list according to claim 1, characterized in that, Predictive component load based on historical protocol adapter metrics includes: predicting future load based on the historical protocol adapter metrics using the following formula: ， in, For the first The protocol adapter in the previous cycle The overall load index For the first The protocol adapter in the previous cycle The load forecast value, This is the balance coefficient.

Images