A communication box centralized bitmap state analysis and multi-device state backfilling method, device and system

Abstract

This invention discloses a method, apparatus, and system for parsing centralized bitmap status of a communication box and backfilling status for multiple devices, relating to the fields of industrial communication gateways and SCADA status synchronization. The method includes: acquiring a message reported by the communication box, which carries multiple status bitmap fields; performing byte order conversion and bitmap expansion on each status bitmap field, and reversing the bit order of the expanded status string to obtain multiple sequential status strings corresponding to different lower-level device number ranges; concatenating the multiple sequential status strings in the order of the lower-level device numbers to obtain a multi-device status string; and backfilling the status information of each lower-level device to the real-time cache of the corresponding lower-level device according to the correspondence between the position of each character in the multi-device status string and the lower-level device number. By refreshing the communication status of multiple lower-level devices with a single communication box sampling, the overhead of polling each device is reduced, ensuring consistency between the centralized status of the communication box and the real-time status of a single device.

Description

Technical Field

[0001] This invention relates to the fields of industrial communication gateways, edge gateways, centralized status acquisition, multi-device bitmap parsing, and SCADA real-time status synchronization, specifically to a method, apparatus, and system for centralized bitmap status parsing and multi-device status backfilling in a communication box. Background Technology

[0002] In large-scale photovoltaic power plants or industrial sites, a single communication box may connect to multiple lower-level control boxes, data acquisition units, or tracking devices. To reduce communication overhead, the communication box typically uses a centralized register bitmap method to report the communication status, alarm status, read flags, and function enable status of lower-level devices. However, the interface display, alarm processing, historical database storage, and maintenance tools of the upper-level SCADA platform are usually displayed and processed at the single-device granularity. Therefore, it is necessary to accurately decompose the multi-segment bitmap reported by the communication box at one time into the status corresponding to each device number and write it back to the real-time cache of each device.

[0003] If the status is still obtained by polling each device, the following problems will arise: First, querying the status of each lower-level device will result in high communication load and slow refresh rate; Second, inconsistencies may easily occur between the centralized status of the communication box and the real-time status of a single device; Third, after the historical data of the communication box is stored in the database, the communication status in the real-time cache of a single device may not be updated synchronously; Fourth, there is a lack of a unified processing mechanism for the communication box's own sensor information, positioning information, battery status, abnormal status and the status of lower-level devices.

[0004] In existing technologies, the inconsistency between the communication box bitmap state and the granularity of the platform's single device state has long been a problem. Multiple 32-bit registers present technical challenges such as mapping byte order, bit order, and device number. If fixed-branch processing logic is written for different device types, the main process needs to be modified when a new device type is added, resulting in poor protocol scalability and project reusability. Exception handling often passively records exceptions at a single stage, lacking a coordinated processing mechanism across caches, databases, and communication connections. Summary of the Invention

[0005] This invention provides a method, apparatus, and system for parsing centralized bitmap status of communication boxes and backfilling status of multiple devices, aiming to solve the following technical problems: converting the multi-segment register bitmaps centrally reported by communication boxes into device-level status that can be directly used by the platform; providing a synchronization mechanism for backfilling the communication box status into the real-time cache of each device; supporting a cache structure that supports centralized refresh of status of multiple lower-level devices and single-device query; reducing the number of polling times of lower-level devices and improving the efficiency of status refresh of large-scale sites.

[0006] To achieve the above-mentioned objectives, the present invention provides the following technical solution: This invention provides a method for parsing the centralized bitmap status of a communication box and backfilling the status of multiple devices, comprising the following steps: First, obtain the message reported by the communication box, which carries multiple status bitmap fields.

[0007] In specific application scenarios, the communication box, as a field device at the site, connects to the data acquisition service in the data acquisition server via a communication link. It is identified as a communication box device in the site device registration configuration, enabling the data acquisition service to select the communication box protocol parser to process its reported data. After receiving the response message from the communication box, the data acquisition service parses the message, including fields such as the communication box address, the polling range of the lower-level control boxes, the communication box reporting time, latitude and longitude, astronomical control parameters such as sunrise and sunset, GPS information, wind speed information, temperature information, battery status, and abnormal alarms. These fields originate from the communication box message or from the field sensors and control units connected to the communication box.

[0008] Second, perform byte order conversion and bitmap expansion on each of the aforementioned status bitmap fields, and perform bit order reversal on the expanded status strings to obtain multiple sequential status strings corresponding to different lower-level device number ranges.

[0009] The communication box response message carries four sets of 32-bit communication status fields, covering lower-level devices 1 to 32, 33 to 64, 65 to 96, and 97 to 128, respectively. Four sets of 32-bit fields are used because a single 32-bit register field can only hold the status of 32 devices; the four sets combined can cover up to 128 devices. For each 32-bit field, a byte order conversion is first performed, converting the byte arrangement in the communication message into an integer that the host can process. Then, this integer is converted into a bit set string, and the bit order is reversed in ascending order of device number, so that the first bit of the string corresponds to the starting device number of the segment, and the last bit corresponds to the ending device number of the segment.

[0010] Third, the multiple sequential status strings are concatenated in order of the lower-level device number to obtain a multi-device status string.

[0011] The four sequential status strings are concatenated into a 128-bit status string according to the device numbers from 1 to 128, where the nth character represents the communication status of the nth subordinate device.

[0012] Fourth, based on the correspondence between the position of each character in the multi-device status string and the number of the lower-level device, the status information of each lower-level device is backfilled into the real-time cache of the corresponding lower-level device.

[0013] A 128-bit status string is written as a sampling field to the communication box's real-time cache and simultaneously to the historical data entry queue. The former is used for real-time display, while the latter is used for background data entry and subsequent device-level status backfilling. When the background historical data entry thread consumes communication box sampling records from the historical data entry queue, it reads the 128-bit status string and iterates through each lower-level device according to the character index of the status string. For devices already existing in the real-time cache, the character corresponding to the device number in the status string is written to the communication status field. This field is used to represent the communication status of a single device, which is read by the SCADA interface, alarm, and query modules at the device level.

[0014] In the above method, the communication box alarm bitmap, read flag bitmap, and function enable bitmap can be parsed using the same byte order conversion, bit set expansion, bit order reversal, segment concatenation, and output by device number.

[0015] The present invention also provides a centralized status processing device for communication boxes, used to implement the aforementioned centralized bitmap status parsing and multi-device status backfilling method for communication boxes, comprising: The bitmap parsing module is used to read multiple status bitmap fields from the communication box message and perform byte order conversion and bitmap expansion on each status bitmap field. This module is responsible for register reading, byte order conversion, bit set expansion, and field mapping.

[0016] The status string concatenation module is used to reverse the position of the expanded status string and concatenate the multiple reversed sequential status strings in the order of the lower-level device numbers to obtain a multi-device status string.

[0017] The historical data entry module is used to write the status strings of the multiple devices into the historical data entry queue.

[0018] The device status backfilling module is used to read the multi-device status string from the historical inbound queue when processing the historical inbound queue, and backfill the status information of each lower-level device to the real-time cache of the corresponding lower-level device according to the correspondence between the position of each character in the multi-device status string and the lower-level device number.

[0019] In a preferred embodiment, the device status backfilling module constructs a key value for the real-time cache of the target lower-level device based on the site number where the communication box is located and the lower-level device number. If the key value exists, the status character at the corresponding position in the multi-device status string is written into the communication status field of the real-time cache. If the key value does not exist, the status backfilling of the current lower-level device is skipped, and the next lower-level device is processed.

[0020] The present invention also provides a centralized status processing system for a communication box, including a data acquisition server, a real-time cache, and a database.

[0021] The acquisition server is used to execute the above-mentioned communication box centralized bitmap status parsing and multi-device status backfilling method, write the multi-device status string into the real-time cache, and write it into the historical entry queue; when the historical entry thread processes the communication box sampling record, it reads the multi-device status string from the historical entry queue, and according to the correspondence between the position of each character in the multi-device status string and the lower-level device number, backfills the status information of each lower-level device into the real-time cache of the corresponding lower-level device.

[0022] The real-time cache is used to store the real-time cache records of each lower-level device. The real-time cache can adopt a key-value storage structure to save the latest status and values ​​of the field devices, allowing for fast retrieval by the interface, alarm, forwarding, and control logic.

[0023] The database is used to store the communication box history records read from the historical inbound queue. The historical archive is used to write the collected process data, status data, or event data into a relational database for traceability, reporting, auditing, and operation and maintenance analysis.

[0024] The present invention has the following beneficial effects: First, this invention converts the multi-segment register bitmap reported centrally by the communication box into a multi-channel device status string that can be directly used by the platform. Multiple lower-level device statuses can be refreshed with a single communication box sampling, which significantly reduces the number of times lower-level devices need to query their communication status one by one and reduces communication overhead.

[0025] Secondly, this invention combines the historical data entry processing of communication boxes with the real-time status backfilling of individual devices, thereby achieving automatic synchronization between the centralized status of communication boxes and the real-time status of individual devices. This ensures data consistency and facilitates the platform to display, alarm, and retrieve communication status at the individual device level.

[0026] Third, this invention solves the problem of inconsistency between register bit order and device number order by reversing bit order and segmenting and splicing, thus avoiding the risk of mapping errors caused by manually maintaining bit order relationships.

[0027] Fourth, the present invention supports a cache structure that enables centralized refresh of device status for up to 128 devices and single-device query, thereby improving the refresh speed of device status at large-scale sites.

[0028] Fifth, this invention integrates the health data of the communication box itself, including sensor information, GPS information, battery status, and abnormal status, with the status of lower-level devices in the same parsing process, which facilitates anomaly location and alarm retrieval. Attached Figure Description

[0029] Figure 1 This is a flowchart for the centralized bitmap status parsing and multi-device status backfilling of the communication box.

[0030] Figure 2 This is a flowchart of the conversion process for four 32-bit bitmap segments.

[0031] Figure 3 This is a schematic diagram illustrating the mapping relationship between device numbers and bitmap fields.

[0032] Figure 4 This is a diagram illustrating the architecture for centralized monitoring of communication boxes and synchronization of individual device status.

[0033] Figure 5 Deploy the topology map on site. Detailed Implementation

[0034] To make the objectives, technical solutions, and advantages of this invention clearer, the technical solutions of this invention will be clearly and completely described below in conjunction with specific embodiments and corresponding drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. Based on the embodiments of this invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this invention.

[0035] The terminology used in the embodiments section of this invention is for the purpose of explaining specific embodiments of the invention only, and is not intended to limit the invention.

[0036] Example 1: Overall Flow and Implementation of the Method This embodiment refers to Figure 1 The flowchart shown here, illustrating the centralized bitmap state parsing and multi-device state backfilling of the communication box, describes a specific implementation of the method of the present invention.

[0037] Step S101: Obtain the message reported by the communication box.

[0038] During site registration, if the device number matches the communication box's designated number, then the communication box data table name and communication box device type are configured for it. When the communication box reports data, the acquisition service in the acquisition server calls the protocol parser to parse the communication box protocol message. This message carries multiple status bitmap fields.

[0039] After receiving the response message from the communication box, the data acquisition service parses the communication box address, the polling range of the lower-level control box, the reporting time of the communication box, latitude and longitude and astronomical control parameters such as sunrise and sunset, global positioning system information, wind speed information, temperature information, battery status, and abnormal alarms carried in the message.

[0040] Step S102: Perform byte order conversion and bitmap expansion on each state bitmap field respectively.

[0041] The protocol parser reads four 32-bit communication status registers, which represent the communication status of lower-level devices numbered 1 to 32, 33 to 64, 65 to 96, and 97 to 128, respectively. For each 32-bit field, a byte order conversion is performed, converting the byte arrangement in the communication message into an integer that the host can process.

[0042] Then, bitmap unrolling is performed on the integer after byte order conversion. Bitmap unrolling refers to converting the integer after byte order conversion into a bit set string. A bit set is a data structure that uses a series of bits to represent data states, with each bit having only two states. After converting the integer into a bit set string, each bit corresponds to a communication state of a lower-level device.

[0043] Step S103: Perform a bit-order reversal on the expanded state string.

[0044] Because there may be a discrepancy between the register bit order and the device number order, it is necessary to reverse the bit order of the expanded bit set string. Bit reversal means reversing the character order of the bit set string so that the first character of the sequence state string corresponds to the starting lower-level device number of the current lower-level device number range.

[0045] Specifically, the system converts each integer into a bit set string and then performs a reversal operation. The reversal operation reverses the character order of the bit set string, ensuring that the first character of the string corresponds to the starting device number of the segment. After reversal, multiple sequential status strings are obtained, each corresponding to a different lower-level device number range.

[0046] Step S104: Concatenate multiple sequential status strings in the order of the lower-level device numbers.

[0047] The system concatenates the four reversed sequential status strings to obtain a multi-device status string. This multi-device status string represents the total communication status string of lower-level devices 1 to 128 reported by the communication box in a single instance. In the multi-device status string, the nth character corresponds to the status of the nth lower-level device.

[0048] Step S105: Based on the correspondence between the position of each character in the multi-device status string and the number of the lower-level device, fill the status information of each lower-level device back into the real-time cache of the corresponding lower-level device.

[0049] The system outputs the multi-device status string along with other real-time fields of the communication box to the real-time cache and simultaneously writes it to the historical database queue.

[0050] After the historical data entry thread records the data in the data entry communication box, it reads the status string of multiple devices and iterates through the position of each character in the status string. For example, the loop indexes from 0 to 127, where index 0 corresponds to the 1st subordinate device and index 127 corresponds to the 128th subordinate device.

[0051] In each loop, the system constructs a key-value pair for the real-time cache of the corresponding lower-level device based on the site number and the current device number. If the key-value pair exists, the system retrieves the status character at the corresponding position from the multi-device status string and writes it into the communication status field of the real-time cache. If the key-value pair does not exist, it means that the target lower-level device is not configured or the cache has not been established. The system skips the status backfilling of the lower-level device and continues to process the next lower-level device.

[0052] The SCADA interface or alarm module can read the real-time cache of a single device to obtain the device communication status synchronized from the centralized messages in the communication box.

[0053] The order of the steps described above is not strictly limited, and those skilled in the art can adjust the execution order of some steps according to actual needs.

[0054] Example 2: Detailed Implementation of Bitmap Conversion This embodiment refers to Figure 2 The flowchart shown describes the conversion process of four 32-bit bitmap segments into a 128-bit status string.

[0055] The communication box response message contains four 32-bit communication status fields, labeled status_1_32, status_33_64, status_65_96, and status_97_128 respectively. See also Figure 3 The diagram shows the mapping relationship between device numbers and bitmap fields. The four sets of fields correspond to the communication status of lower-level devices numbered 1 to 32, 33 to 64, 65 to 96, and 97 to 128, respectively.

[0056] For each 32-bit field, byte order conversion is performed first. Since the byte order in the communication message may differ from the host processor's byte order, the message byte order needs to be converted to an integer that the host can process. For example, for messages transmitted in big-endian byte order, byte order reversal is required on a little-endian host to rearrange the message bytes according to the host's byte order.

[0057] After byte order conversion, an integer value that the host can process is obtained. This integer is then converted into a bit set string. For example, the 32-bit binary representation of the integer value 0x0000000F is "000000000000000000000000001111", which, after bitmap expansion, results in a bit set string of length 32.

[0058] Then, a bitwise reversal is performed on the bit set string. Bitwise reversal reverses the order of the characters in the string. For example, the bit set string "00000000000000000000000000001111" corresponding to devices 1 to 32 becomes "1111000000000000000000000000000000" after reversal, so that the first character of the string corresponds to the 1st subordinate device and the last character corresponds to the 32nd subordinate device.

[0059] After performing the byte order conversion, bit set expansion, and bit order reversal on the four fields respectively, four sequential status strings are obtained. These four sequential status strings are then concatenated in order of device number from 1 to 128 to obtain a multi-device status string of length 128. In this multi-device status string, the first character corresponds to the communication status of the first subordinate device, the second character corresponds to the communication status of the second subordinate device, and so on, with the 128th character corresponding to the communication status of the 128th subordinate device.

[0060] Using the bitmap conversion method described above, the communication box alarm bitmap, read flag bitmap, and function enable bitmap can be parsed using the same byte order conversion, bit set expansion, bit order reversal, segment concatenation, and output by device number.

[0061] Example 3: Implementation Method for Communication Quality Monitoring In monitoring the communication link quality between the communication box and the data acquisition server, the packet loss rate of data transmission time slots can be calculated using the following method. This embodiment is an auxiliary implementation method for monitoring the status of the communication box and is used to evaluate the communication link quality.

[0062] The link status acquisition module records the number of packets sent by the acquisition server within a data transmission time slot, denoted as send_num. The link status feedback module counts the number of packets received by downstream devices based on the communication link within the same data transmission time slot, denoted as plc_recv_num, and feeds back the statistical results to the link status acquisition module.

[0063] The link state acquisition module calculates the packet loss rate of the data transmission time slot based on the number of sent packets (send_num) and the number of received packets (plc_recv_num), denoted as Plclossrate: Plclossrate = (1 - plc_recv_num / send_num) × 100% Wherein, send_num represents the number of packets sent by the acquisition server within a data transmission time slot; plc_recv_num represents the number of packets received by the downstream device based on the communication link within the same data transmission time slot; and Plclossrate represents the packet loss rate of the data transmission time slot.

[0064] In the above formula, when plc_recv_num equals send_num, the packet loss rate is 0, indicating good communication link quality; when plc_recv_num is less than send_num, the packet loss rate is greater than 0, indicating that there is packet loss. The higher the packet loss rate, the worse the communication link quality.

[0065] Those skilled in the art will understand that the above formula can be used to evaluate the communication quality of the communication box data reporting link, but this communication quality monitoring is not a necessary step in realizing the core scheme of bitmap state parsing and state backfilling of the present invention.

[0066] Example 4: Detailed Implementation of Equipment Status Backfilling This embodiment describes in detail the specific process by which the device status backfilling module backfills multiple device status strings to the real-time cache of each lower-level device.

[0067] After the multi-device status string is written as a sampling field to the communication box's real-time cache, it is simultaneously written to the historical data entry queue. The background historical data entry thread is responsible for consuming the historical data entry queue and writing it to the database. When processing communication box sampling records, the historical data entry thread reads this multi-device status string.

[0068] The historical data entry thread traverses each lower-level device by the character index of the status string. Assuming the station number where the communication box is located is station_id and the lower-level device number is device_id, the system constructs the key value of the real-time cache of the target lower-level device as "station:station_id:device:device_id".

[0069] For the character position at index i, where i starts from 0, the corresponding lower-level device number is i+1. The system first checks if the key value "station:station_id:device:(i+1)" exists in the real-time cache.

[0070] If the key value exists, it means that the lower-level device has been registered in the site configuration and a real-time cache record has been established. The system extracts the character at the i-th position from the multi-device status string and writes this character into the communication status field of the real-time cache. This communication status field is used to represent the communication status of a single device, which can be read by the SCADA interface, alarm module, and query module at the device level.

[0071] If the key value does not exist, it means that the lower-level device is not configured or the cache has not been established. The system skips the status backfilling of the lower-level device and continues to process the next lower-level device. The system does not automatically create status records for unconfigured devices to avoid generating false device statuses.

[0072] Using the above method, a single communication box sampling can refresh the status of up to 128 downstream devices, and the backfill operation only updates the configured devices, without generating invalid status records.

[0073] Example 5: Device Implementation This embodiment refers to Figure 4 The diagram shown illustrates a specific implementation of a centralized monitoring and single-device status synchronization architecture for communication boxes.

[0074] The device includes a bitmap parsing module, a status string splicing module, a history entry module, and a device status backfilling module.

[0075] The bitmap parsing module reads multiple status bitmap fields from the communication box message and performs byte order conversion and bitmap expansion on each field. The input to the bitmap parsing module is the original communication box message, and the output is the status string after byte order conversion and bit set expansion. This module can be implemented using a protocol parser, responsible for register reading, byte order conversion, bit set expansion, and field mapping.

[0076] The status string concatenation module reverses the bit order of the expanded status string and concatenates the reversed sequential status strings in the order of the lower-level device numbers to obtain a multi-device status string. The input to the status string concatenation module is multiple sequential status strings, and the output is the concatenated multi-device status string.

[0077] The historical data entry module is used to write multi-device status strings into the historical data entry queue. The historical data entry module can be implemented using a message queue mechanism, placing communication box sampling records (containing multi-device status strings) into the queue for consumption by background threads.

[0078] The device status backfilling module is used to read multiple device status strings from the historical inbound queue when processing the historical inbound queue. Based on the correspondence between the position of each character in the multiple device status string and the number of the lower-level device, the status information of each lower-level device is backfilled into the real-time cache of the corresponding lower-level device.

[0079] In a preferred embodiment, the device status backfilling module constructs a key value for the real-time cache of the target lower-level device based on the site number where the communication box is located and the lower-level device number. If the key value exists, the status character at the corresponding position in the multi-device status string is written into the communication status field of the real-time cache; if the key value does not exist, the status backfilling of the current lower-level device is skipped, and the next lower-level device is processed.

[0080] Data is transferred between modules via a standard interface. The bitmap parsing module passes the parsed status string to the status string concatenation module; the status string concatenation module passes the concatenated multi-device status strings to the historical data entry module and the real-time cache respectively; the historical data entry module writes the multi-device status strings into the historical data entry queue; and the device status backfilling module consumes data from the historical data entry queue and performs the backfilling operation.

[0081] The above division of modules is merely a logical functional division. In implementing this invention, the functions of each module can be implemented in one or more software and / or hardware components. These modules can be implemented entirely in software through processing element calls, entirely in hardware, or some modules can be implemented in software and others in hardware.

[0082] Example 6: System Implementation This embodiment refers to Figure 5 The on-site deployment topology diagram shown illustrates a specific implementation of the centralized status processing system for the communication box.

[0083] The system includes a data acquisition server, a real-time cache, and a database. The deployment relationship between the data acquisition server, real-time cache, and database is as follows: lower-level devices communicate with a communication box, the communication box connects to the data acquisition server via a communication link, the data acquisition server interacts with both the real-time cache and the database, and the web platform reads the device status from the real-time cache.

[0084] The acquisition server is used to execute the aforementioned method for parsing the centralized bitmap status of communication boxes and backfilling the status of multiple devices. Specifically, the acquisition server receives the messages reported by the communication boxes, parses multiple status bitmap fields in the messages, and performs byte order conversion, bitmap expansion, bit order reversal, and concatenation operations to obtain the multi-device status string. The acquisition server writes the multi-device status string into the real-time cache and into the historical entry queue. When the historical entry thread processes the communication box sampling records, the acquisition server reads the multi-device status string from the historical entry queue and, based on the correspondence between the position of each character in the multi-device status string and the lower-level device number, backfills the status information of each lower-level device into the real-time cache of the corresponding lower-level device.

[0085] The real-time cache is used to store real-time cache records for each lower-level device. The real-time cache can use a key-value storage structure, with a combination of station number and device number as the key, storing fields such as the device's current value, communication status, alarm status, and acquisition time. The communication status field in the real-time cache represents the communication status of a single device, allowing the SCADA interface, alarm module, and query module to quickly read the data at the device level.

[0086] The database stores the historical records of communication boxes read from the historical inbound queue. The database can be a relational database and stores communication box sampling records, including fields such as site number, communication box device number, sampling time, status strings for multiple downstream devices, and alarm bitmaps. The historical records are used for traceability, reporting, auditing, and operational analysis.

[0087] The data acquisition server, real-time cache, and database work together to achieve automatic synchronization between the centralized status of the communication box and the real-time status of individual devices. The data acquisition server handles protocol parsing and status transitions, the real-time cache provides high-speed status queries, and the database provides persistent storage. Together, these three components constitute a complete centralized status processing system for the communication box.

[0088] Example 7: Parameter Configuration and Anomaly Handling Implementation Method This embodiment describes the configurable range of each parameter, the exception handling method, and the extended implementation method in this invention.

[0089] Parameter configuration: The station identifier (station_id) can be derived from the database station table or registration message and is used to construct cache key-value pairs, device sets, and historical record indexes. The station identifier can be replaced with a gateway number, site number, or a unique identifier within the tenant.

[0090] The device ID (device_id) is derived from the site's device inventory and is used to locate a single device's real-time cache and device-level status. The device ID can be expanded to include a composite ID, a device serial number, or a logical address.

[0091] Device type or version is used to select the parser, history table, and field mapping. Device type can be replaced with protocol encoding, plug-in identifier, or model encoding.

[0092] The sampling time can be derived from device messages, system time, or communication box time fields, and is used for historical table segmentation, time series queries, and alarm judgment. The sampling time can be selected according to the field time, server time, or calibration time.

[0093] The cache key-value prefix can be a combination of project code, site number, or device number to achieve isolation for multiple projects and sites. The cache key-value prefix can also add tenant, region, line, or device group levels.

[0094] Exception handling: When the registration information cannot match a site, the system refuses to add the connection to the set of valid sites and releases the current session resources.

[0095] When the device protocol type is unknown or the configuration is missing, the system retains error logs and does not use the default parser to forcibly parse business messages, thus preventing erroneous data from entering the real-time cache.

[0096] When the message length, CRC check, bitmap length, or JSON field does not meet the requirements, the system discards the current frame or current record and recovers through error counting, buffer cleanup, or retry strategies.

[0097] When a database, disk, or authorization interface experiences a temporary failure, the system will enter a mode that, according to its configuration, delays retrying, only records the status, or stops the service of the specified item to avoid affecting unrelated sites.

[0098] Extended implementation method: In the extended implementation, the status bit depth can be expanded to 64 bits, 256 bits, or more, requiring only adjustments to the number of segments and the traversal range. Alarm statuses, read flags, and function enablements, in addition to communication status, can utilize the same bitmap expansion and backfilling mechanism. Backfilled fields can be expanded to include communication quality, last update time, and exception reason codes. The communication box can be replaced with other edge gateways or centralized data collectors, still employing a centralized bitmap-to-device-level status mapping implementation.

[0099] The above description is merely a preferred embodiment of the present invention and is not intended to limit the invention. Various modifications and variations can be made to the present invention by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A method for centralized bitmap state parsing and multi-device state backfilling of a communication box, characterized in that, include: Obtain the message reported by the communication box, the message carrying multiple status bitmap fields; Perform byte order conversion and bitmap expansion on each of the aforementioned status bitmap fields, and perform bit order reversal on the expanded status strings to obtain multiple sequential status strings corresponding to different lower-level device number ranges; Multiple sequential status strings are concatenated in order of their respective lower-level device numbers to obtain a multi-device status string; Based on the correspondence between the position of each character in the multi-device status string and the number of the lower-level device, the status information of each lower-level device is backfilled into the real-time cache of the corresponding lower-level device.

2. The method for centralized bitmap state parsing and multi-device state backfilling of a communication box according to claim 1, characterized in that, The multiple status bitmap fields are four 32-bit fields, which correspond to the communication status of the 1st to 32nd lower-level devices, the 33rd to 64th lower-level devices, the 65th to 96th lower-level devices, and the 97th to 128th lower-level devices, respectively.

3. The method for centralized bitmap state parsing and multi-device state backfilling of a communication box according to claim 1, characterized in that, The bitmap unpacking includes converting the integer after byte order conversion into a bit set string; the bit order reversal includes reversing the character order of the bit set string so that the first character of the sequence state string corresponds to the starting lower-level device number of the current lower-level device number range.

4. The method for centralized bitmap state parsing and multi-device state backfilling of a communication box according to claim 1, characterized in that, The step of backfilling the status information of each lower-level device to the real-time cache of the corresponding lower-level device includes: Construct the key-value pair for the real-time cache of the target lower-level device based on the site number where the communication box is located and the lower-level device number; If the key value exists, the status character at the corresponding position in the multi-device status string is written into the communication status field of the real-time cache; If the key value does not exist, skip the status backfilling of the current lower-level device and continue processing the next lower-level device.

5. The method for centralized bitmap state parsing and multi-device state backfilling of a communication box according to claim 1, characterized in that, The method further includes: The multi-device status string is written as a sampling field of the communication box into the real-time cache of the communication box and into the historical storage queue. When the historical data entry thread processes the communication box sampling records, it reads the multi-device status string from the historical data entry queue, and fills the status information of each lower-level device back into the real-time cache of the corresponding lower-level device according to the correspondence between the position of each character in the multi-device status string and the lower-level device number.

6. The method for centralized bitmap state parsing and multi-device state backfilling of a communication box according to claim 1, characterized in that, The message also carries the communication box's own status information, which includes at least one of the following: communication box address, polling range of the lower-level control box, reporting time, global positioning system information, wind speed information, temperature information, battery status, and abnormal alarm information.

7. The method for centralized bitmap state parsing and multi-device state backfilling of a communication box according to claim 1, characterized in that, The status bitmap field includes at least one of the following: communication status bitmap, alarm status bitmap, read flag bitmap, and function enable bitmap.

8. A centralized status processing device for communication boxes, used to execute the centralized bitmap status parsing and multi-device status backfilling method for communication boxes as described in any one of claims 1 to 7, characterized in that, include: The bitmap parsing module is used to read multiple status bitmap fields from the communication box message, and perform byte order conversion and bitmap expansion on each of the status bitmap fields respectively; The status string concatenation module is used to reverse the position order of the expanded status string and concatenate the multiple reversed sequential status strings in the order of the lower-level device numbers to obtain a multi-device status string. The historical data entry module is used to write the status strings of the multiple devices into the historical data entry queue; The device status backfilling module is used to read the multi-device status string from the historical inbound queue when processing the historical inbound queue, and backfill the status information of each lower-level device to the real-time cache of the corresponding lower-level device according to the correspondence between the position of each character in the multi-device status string and the lower-level device number.

9. The centralized status processing device for a communication box according to claim 8, characterized in that, The device status backfilling module constructs a key value for the real-time cache of the target lower-level device based on the site number where the communication box is located and the lower-level device number. If the key value exists, the status character at the corresponding position in the multi-device status string is written into the communication status field of the real-time cache. If the key value does not exist, the status backfilling of the current lower-level device is skipped, and the next lower-level device is processed.

10. A centralized status processing system for a communication box, characterized in that, This includes the data acquisition server, real-time cache, and database; The acquisition server is used to execute the communication box centralized bitmap status parsing and multi-device status backfilling method as described in any one of claims 1 to 7, write the multi-device status string into the real-time cache, and write it into the historical entry queue; when the historical entry thread processes the communication box sampling record, it reads the multi-device status string from the historical entry queue, and according to the correspondence between the position of each character in the multi-device status string and the lower-level device number, backfills the status information of each lower-level device into the real-time cache of the corresponding lower-level device; The real-time cache is used to store the real-time cache records of each lower-level device; The database is used to store the communication box history records read from the historical inbound queue.

Images