Modbus homomorphic memory mapping-based heterogeneous device data aggregation method and edge gateway

Abstract

The application relates to a heterogeneous device data aggregation method based on a ModBus homomorphism memory mapping and an edge gateway, and relates to the field of heterogeneous device data aggregation. A device shadow pool is established in the edge gateway, a unified memory mapping is obtained, a target node is polled according to the unified memory mapping, ModBus loads are stripped from returned frames of the target node and are verified, telemetry data is restored, control instructions issued by a man-machine interface or a cloud are written into a control instruction queue together with target register addresses, when there are control instructions to be processed, a control area base address is calculated according to a device species number and a block length, a write instruction is issued to the target node after a target register address is verified, and polling is restored after processing is completed, so that the delay and congestion of control signals in a multi-device mixed loading scene are avoided.

Description

Technical Field

[0001] This invention relates to the field of heterogeneous device data aggregation, specifically to a heterogeneous device data aggregation method and edge gateway based on ModBus homomorphic memory mapping. Background Technology

[0002] The ModBus protocol addresses device data using register addresses. Edge gateways use the ModBus protocol to collect telemetry data such as voltage, current, temperature, humidity, and location returned by sub-devices like photovoltaic pavers, streetlights, and downlights, and forward control commands such as switching, dimming, and color adjustments to these sub-devices. As the types and number of connected sub-devices increase, the edge gateway needs to aggregate register data from multiple heterogeneous sub-devices within the same memory and addressing system, and forward control commands from the human-machine interface or the cloud while collecting telemetry data.

[0003] Patent CN111800524B discloses a "Method for Parsing the Original Address of Multiple Data Paths in Modbus Messages." This method, during data acquisition, calculates the data offset address and generates a field truncation index address to locate fields. After receiving the binary byte stream returned by the device, the gateway uses an original address parsing algorithm to perform data truncation, shift alignment, base conversion, and field concatenation to restore various physical values ​​and report them. Patent CN111901214B discloses "A Power Monitoring Serial Communication Method and System Based on an Optimized Polling Mechanism." This method, at the gateway scheduling level, operates by sequentially polling and reading registers from all slave nodes at fixed intervals, employing a serial blocking communication logic where control commands are issued sequentially in queue order.

[0004] However, in actual engineering scenarios where various heterogeneous sub-devices such as photovoltaic floor tiles, streetlights, and downlights are mixed, the aforementioned existing technologies have revealed many insurmountable defects. On the one hand, the data acquisition schemes mentioned above are based on configuring address tables independently for each device and shifting and splicing fields at the application layer, lacking a unified address base and expansion margin across device species. Once a certain type of device adds or deletes fields or undergoes firmware iteration, it is very easy to cause the starting address of subsequent fields to shift, resulting in address misalignment and incompatibility between old and new devices. Moreover, the cumbersome byte-level operations severely squeeze the CPU computing power of the gateway, causing a significant slowdown in the throughput of telemetry data acquisition when multiple nodes are connected. On the other hand, the aforementioned scheduling schemes adopt a fixed-period serial blocking mechanism. When a control command is suddenly issued from the human-machine interface or the cloud, the command must be queued in the same serial queue, waiting for the current lengthy telemetry polling and blocking response to end before it can be issued. This cannot achieve asynchronous decoupling under high concurrency, which can easily cause control lag or even command congestion and loss.

[0005] To address the aforementioned shortcomings, a technical solution is provided. Summary of the Invention

[0006] To address the technical problems raised in the background section, this invention is proposed. This invention provides a method for heterogeneous device data aggregation based on ModBus homomorphic memory mapping and an edge gateway.

[0007] This invention is achieved through the following technical solution:

[0008] A heterogeneous device data aggregation method based on ModBus homomorphic memory mapping includes:

[0009] A device shadow pool is established at the edge gateway. The ModBus register address space is divided into a general network identity area, a read-only telemetry area, and a read-write control area. For each device species, a fixed-length data block with a reserved check area at the end is allocated in the read-only telemetry area and the read-write control area in single-byte alignment. The length of the fixed-length data block is the block length, resulting in a unified memory mapping.

[0010] Based on the unified memory mapping, the target node is polled, the device species number is obtained by reading the general network identity area of ​​the target node, the ModBus payload is extracted from the return frame of the target node and verified, the ModBus payload that passes the verification is structurally aligned and then copied into the memory and written into the data block corresponding to the device species number in the device shadow pool, and the telemetry data is restored.

[0011] The control commands issued by the human-machine interface or the cloud, along with the target register address, are written into the control command queue. The control command queue is checked during the polling intervals. If there are control commands to be processed, the control area base address is calculated based on the device species number and block length. After verifying the target register address, the write command is sent to the target node. After processing is completed, polling is resumed.

[0012] Furthermore, the output steps for unified memory mapping are as follows:

[0013] A device shadow pool is established in the edge gateway memory, and a general network identity zone, a read-only telemetry zone, and a read-write control zone are divided. Each zone is anchored with a fixed base address to obtain a partitioned memory mapping.

[0014] Furthermore, the output steps of the unified memory mapping also include:

[0015] In partitioned memory mapping, a fixed-length data block is allocated for each device species in the read-only telemetry area and the read-write control area. The front of the fixed-length data block is the valid data field and the tail is the reserved verification area. When the device function is iterated, only the field is added in the reserved verification area without changing the starting address and arrangement order of the existing fields.

[0016] Ensure that the shadow structure on the gateway side and the structure on the node side are arranged in single-byte alignment and have the same binary byte order, and output a unified memory mapping.

[0017] Furthermore, the fixed base address is anchored as follows: the base address of the general network identity area is 1000, the base address of the read-only telemetry area is 8192, and the base address of the read-write control area is 20480. The read-only telemetry area and the read-write control area are physically isolated, and the control commands written to the read-write control area do not fall into the read-only telemetry area.

[0018] Furthermore, the analysis steps for the validated ModBus load include:

[0019] Read the online status of the target node in the device shadow pool: If it is unknown or offline, enter the identity detection mode, and only issue the command to read the general network identity area to obtain the device species number and update the online status; if it is online, enter the telemetry reading mode, select the address range to be read in this round according to the device species number and the polling cycle count of each sensor, and issue the command to read the address range to be read in this round.

[0020] Furthermore, the analysis steps for the verified ModBus load also include:

[0021] Based on the header, length field, and trailer of the return frame from the target node, the pure ModBus payload and source node address are extracted by using the length field as a pointer to cross the location. The payload is then checked sequentially by the source node address, length, CRC, and function code. The length check involves comparing the number of extracted ModBus payload bytes with the expected number of payload bytes calculated based on the number of registers contained in the address range to be read in this round, to obtain the ModBus payload that passes the check.

[0022] Furthermore, the steps to reconstruct the telemetry data include:

[0023] Perform structural alignment verification on the ModBus loads that have passed the verification, and obtain the structural alignment verification value;

[0024] When the structural alignment check value indicates that the structures at both ends are homomorphic, the ModBus payload is copied into the data block corresponding to the device shadow pool and the device species number, and into the target byte range corresponding to the address range to be read in this round, after memory copying. This restores the telemetry data in IEEE-754 floating-point format and updates the online status. When the structural alignment check value indicates structural mismatch, the ModBus payload is discarded, the online status of the target node is set to zero and marked as structural mismatch, triggering a re-read handshake for the firmware version of the target node.

[0025] Furthermore, the steps for performing structural alignment verification on the verified ModBus loads include:

[0026] The field offset sequence is formed by arranging the field boundaries of a fixed-length data block according to the prefix sum. The reserved check area is determined by the last segment of the field offset sequence. The reserved check area is filled by nodes with reserved reference constants.

[0027] The structural alignment check value is obtained by summing the ModBus loads that pass the check byte by byte within the reserved check area.

[0028] Furthermore, the determination steps for determining the structural homomorphism of the two ends of the structure by the structural alignment check value include: comparing the structural alignment check value with the expected value corresponding to the reserved reference constant; if they are consistent, the two ends of the structure are determined to be homomorphic; if they are inconsistent, the structure is determined to be mismatched.

[0029] Furthermore, the steps for calculating the base address of the control area include:

[0030] When receiving operations from human-machine interface controls or cloud-based commands, because the data flow identifiers of the human-machine interface controls are bound one-to-one with the physical addresses of ModBus registers, control instructions containing target node identifiers, target register addresses, and control values ​​are directly generated without going through an address translation table.

[0031] Write control instructions into the control instruction queue in a non-blocking manner; establish an arithmetic addressing relationship so that the control area base address is equal to the sum of 20480, the device species number minus one, and the block length. Calculate the control area base address of the target node based on this, and verify that the target register address falls into a valid control block with the control area base address as the starting point and a length equal to the block length.

[0032] Furthermore, the steps to resume polling include: checking the control instruction queue during the polling interval, suspending and saving the current polling position when it is not empty, issuing a write instruction to the control area register of the target node first, and restoring the saved current polling position after receiving an acknowledgment or timeout.

[0033] Furthermore, it also includes: when the target node switches from offline to online, the polling cycle count of each of its sensors is set to full so that full harvesting is forced in the next cycle; and the number of data blocks contained in the address range to be read in this round decreases as the backlog depth of the control command queue in the previous cycle increases, so that the polling rounds of the telemetry reading mode and the backlog depth of the control command queue form a mutually restrictive closed loop.

[0034] Furthermore, it also includes: maintaining a change register bitmap covering the read-only telemetry area; setting the corresponding bit in the change register bitmap when the value copied to memory differs from the original value in the device shadow pool; periodically scanning the change register bitmap, merging consecutively set bits into consecutive address ranges, generating incremental reporting messages only for consecutive address ranges, and clearing the change register bitmap after reporting.

[0035] Furthermore, it also includes: a separate OTA upgrade area with a base address of 32768 is allocated in the partition memory mapping. The OTA upgrade area is physically isolated from the read-only telemetry area and the read-write control area. The OTA upgrade area carries block handshake upgrades with block indexes and firmware CRC32. When a block is lost, only the data block corresponding to the block index is retransmitted. The upgrade does not affect the services of other partitions.

[0036] An edge gateway includes a memory, a processor, and a computer program stored in the memory and executable on the processor.

[0037] Compared with the prior art, the beneficial effects of the present invention are:

[0038] This invention establishes a device shadow pool at the edge gateway, dividing the ModBus register address space into a general network identity area, a read-only telemetry area, and a read-write control area, thus creating a unified address base for various heterogeneous sub-devices. Fixed-length data blocks and reserved checksums are allocated to different segments according to the device species. This ensures that when subsequent device function iterations add fields, only the front end of the reserved checksum is drawn, without affecting the starting address and block length of existing fields, and the addressing of other device species remains unaffected. The gateway's underlying core program for handling telemetry and control does not need to be repeatedly rewritten; only the byte length and other definitions of each valid data field of the iterated device species need to be updated synchronously at both the gateway and node ends. The gateway polls the target node based on the base address and fixed-length data blocks, extracts the ModBus payload from the return frame, performs structural alignment verification, and then uses memory copying to move the entire byte stream into the data block of the device shadow pool. The data restoration process abandons the traditional application-layer field-by-field shifting, splicing, and number system conversion operations, directly restoring the telemetry data from the underlying memory, reducing the computational overhead of the microcontroller when performing multi-node data acquisition. For operations sent via the human-machine interface or the cloud, the control command, along with the target register address, is stored in the control command queue. The gateway checks the control command queue during the intervals of continuous telemetry polling, calculates the control area base address according to the device species number in an arithmetic progression, and issues a write command. This ensures that control actions are not blocked by lengthy telemetry reads and avoids delays and congestion in control signals in scenarios with multiple devices.

[0039] A traffic split path is introduced between identity detection mode and telemetry reading mode. The gateway blocks invalid queries to offline nodes based on online status and selects expired sensor data blocks for reading based on polling clock count, avoiding invalid reads of slowly changing physical quantities and maintaining the refresh throughput of valid data. When stripping return frame data, the length field value is used as the step size to directly locate the frame tail, skipping the pseudo-packet tail bytes composed of service bytes to prevent the message from being truncated midway. In the structure alignment verification step, the reserved verification area is calculated according to the field boundary prefix sum. For ModBus payloads that have passed the transport layer verification, the reserved verification area is summed byte by byte within the reserved verification area. The structure alignment verification value is compared with the expected value. When byte layout shift causes non-zero bytes to move into the reserved verification area, the structure alignment verification value deviates from the expected value. Based on this, the memory copy operation is intercepted, reducing the probability of layout shift errors being silently written to floating-point format. The read budget decreases with the backlog depth of the control command queue from the previous cycle. The number of data blocks allowed to be read in telemetry read mode is reduced according to the backlog depth, allowing bus transmit / receive time slots to be allocated to control actions. This creates mutual constraints between read and write cycles, maintaining a balance between concurrent read and write operations on the bus. The gateway sets the corresponding bits in the register bitmap based on the numerical differences before and after memory copying, grouping consecutive set bits into consecutive address ranges. Incremental reporting messages are generated only for consecutive address ranges with numerical jumps, controlling the amount of communication data uploaded to the wide area network. Attached Figure Description

[0040] To more clearly illustrate the technical solutions of the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. The following drawings are not drawn to scale according to the actual size, but are intended to show the main idea of ​​the present invention.

[0041] Figure 1 This is a system block diagram of an edge gateway;

[0042] Figure 2 This is a flowchart of a heterogeneous device data aggregation method based on ModBus homomorphic memory mapping;

[0043] Figure 3 To unify the memory mapping principle diagram;

[0044] Figure 4 This is a schematic diagram of the homomorphic memory mapping principle.

[0045] Figure 5 This is a schematic diagram of structural alignment verification;

[0046] Figure 6 This is a schematic diagram of an arithmetic progression addressing relationship;

[0047] Figure 7 This is a diagram illustrating incremental reporting. Detailed Implementation

[0048] The technical solutions in the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are also within the scope of protection of the present invention.

[0049] Example 1

[0050] The edge gateway used in this embodiment integrates a microcontroller scheduling core, a 4G communication module, a local human-machine interface touchscreen, and a wireless mesh and serial communication bus. A globally unique device shadow pool is established in the gateway's memory for real-time mapping of the register states of each sub-device in the physical world. The underlying reasons are analyzed as follows: Heterogeneous device access requires repeated modifications to the gateway's underlying source code. This is because existing gateways forcibly bind the register address table of each type of device to a dedicated parsing program and business processing code, lacking a unified address base across device types and sufficient space to accommodate subsequent field expansions. Once a field is added or deleted for a certain type of device, the starting address of subsequent fields shifts accordingly, resulting in misalignment with the old device addresses. Restoring high-precision data consumes computational resources because the arrangement of the binary byte stream returned by the bus is inconsistent with the memory arrangement of the target variables within the gateway. The returned bytes must be shifted and concatenated item by item before type conversion. Control commands are delayed because the gateway uses synchronous blocking single-line polling, and the human-machine interface control addresses and ModBus register addresses belong to two different systems, requiring address translation tables before being sent.

[0051] It should be further pointed out that even if the gateway and node adopt the same memory arrangement to replace item-by-item shifting with memory copying, memory copying is still an indiscriminate whole-segment transport: the CRC check at the end of the message can only guarantee that the transmitted bits have not been flipped due to errors, but cannot guarantee that the field layout of the sending end and the field layout of the shadow structure of the receiving end are aligned byte by byte. When the node firmware iterates and inserts new fields, the node is misidentified as having a device species number, or frame reassembly causes the overall byte offset, the field boundaries are shifted accordingly. The memory copy will move the shifted bytes into the wrong floating-point field, resulting in an erroneous value that passes the CRC check but does not match the actual physical quantity. This erroneous value will not trigger any transport layer alarms and is a form of hidden data pollution. In the following steps, the structure alignment check in step S23 is designed precisely for this substantial reason. Figure 2 As shown, the heterogeneous device data aggregation method based on ModBus homomorphic memory mapping includes steps S10, S20 and S30.

[0052] Step S10: Establish a device shadow pool at the edge gateway, divide the ModBus register address space into a general network identity area, a read-only telemetry area, and a read-write control area, and allocate a fixed-length data block with a reserved check area at the end in single-byte alignment in the read-only telemetry area and the read-write control area for each device species. The length of the fixed-length data block is the block length, thus obtaining a unified memory mapping.

[0053] Step S10 aims to establish a unified address base for multiple heterogeneous sub-devices within the same memory and addressing system. This involves creating a device shadow pool in the edge gateway memory, dividing the ModBus register address space into a general network identity area, a read-only telemetry area, and a read / write control area using fixed base addresses, and allocating fixed-length data blocks with reserved checksums at the end to each device species within the read-only telemetry area and read / write control area, resulting in a unified memory mapping. Because the base address and block length are fixed, the register address of any field for any device species can be uniquely determined by the segment base address and the offset within the block. When adding, deleting, or iterating fields in a device species, the existing field addresses are extended within the reserved checksum without altering the existing field addresses. The gateway's underlying source code does not need to be rewritten to adapt to new devices. The partition base address and block length output in step S10 are used by step S20 to locate node registers in the address grid according to the device species number, and by step S30 to calculate the control area base address using arithmetic progression based on the block length. Step S10 includes steps S11, S12, and S13.

[0054] Reference Figure 3 The diagram illustrates the principle of unified memory mapping.

[0055] Figure 3This demonstrates how the device shadow pool in the edge gateway's memory divides the ModBus register address space into a general network identity area, a read-only telemetry area, and a read / write control area using fixed base addresses, and allocates fixed-length data blocks for each device species. The diagram illustrates the general network identity area using register address 1000 as the base address and the range 1000 to 8191; the read-only telemetry area using register address 8192 as the base address and the range 8192 to 20479; and the read / write control area using register address 20480 as the base address and the range 20480 to 32767. This shows that the three segments are arranged using three base addresses (1000, 8192, and 20480) rather than consecutively, reserving address space between adjacent areas to accommodate horizontal expansion of data blocks within subsequent areas. Within the read-only telemetry area and the read-write control area, a fixed-length address space is allocated to each device type—photovoltaic pavers, streetlights, and downlights—as a fixed-length data block, the length of which is the block length. The fixed-length data block shown separately below the diagram has a front section representing valid data fields and a rear section representing a reserved check area. This indicates that during device function iteration, fields are added only to the reserved check area without changing the starting address and arrangement order of existing fields. The read-only telemetry area and the read-write control area do not overlap in address allocation, achieving physical isolation between them. This means that the target register address of control instructions written to the read-write control area is always no less than 20480 and falls outside the read-only telemetry area address range of 8192 to 20479, preventing accidental writing of acquired data at the addressing level.

[0056] Step S11: Establish the device shadow pool in the gateway memory and divide it into the general network identity area, the read-only telemetry area, and the read-write control area. Each area is anchored with a fixed base address: the base address of the general network identity area is 1000, the base address of the read-only telemetry area is 8192, and the base address of the read-write control area is 20480. The read-only telemetry area and the read-write control area are physically isolated, and the control instructions written to the read-write control area do not fall into the read-only telemetry area, thus obtaining the partitioned memory mapping.

[0057] Step S11 establishes a device shadow pool in the gateway memory and divides it into a general network identity area, a read-only telemetry area, and a read-write control area. The device shadow pool is an array of structures addressed by node indexes. Each element corresponds to a filed sub-device. Within each element, all register images of the sub-device are arranged consecutively in the order of general network identity area, read-only telemetry area, and read-write control area. The general network identity area uses register address 1000 as its base address, the read-only telemetry area uses register address 8192 as its base address, and the read-write control area uses register address 20480 as its base address. The base addresses of the three areas are fixed values ​​given by the configuration and remain consistent across the gateway and all nodes. Using the three base addresses 1000, 8192, and 20480 instead of arranging them consecutively is to reserve address space between adjacent areas to accommodate the horizontal expansion of data blocks within subsequent areas, ensuring that the expansion of one area does not encroach on adjacent areas. The register address range for the general network identity zone is 1000 to 8191, the register address range for the read-only telemetry zone is 8192 to 20479, and the register address range for the read-write control zone is 20480 to 32767. The gateway only allows any write register instruction if the target register address is not less than 20480; write instructions with a target register address less than 20480 are rejected. Therefore, control instructions written to the read-write control zone always have a target register address no less than 20480, falling outside the read-only telemetry zone address range of 8192 to 20479, resulting in a physically isolated partitioned memory mapping between the read-only telemetry zone and the read-write control zone.

[0058] Step S12: On the partitioned memory mapping, allocate the fixed-length data block for each device species in the read-only telemetry area and read-write control area. The fixed-length data block has a valid data field at the front and a reserved verification area at the back. When the device function is iterated, only the field is added in the reserved verification area without changing the starting address and arrangement order of the existing fields.

[0059] In step S12, fixed-length data blocks are allocated for each device species in the read-only telemetry area and read-write control area in the partitioned memory mapping. Device species refer to the sub-device categories determined during the design phase; photovoltaic floor tiles, streetlights, and downlights each constitute one device species. The length of each fixed-length data block is the block length. The block length is determined as follows: first, the alignment boundary is determined. The alignment boundary is the address alignment granularity required for the gateway microcontroller to perform one memory transfer. This alignment granularity is a power of 2. Taking a power of 2 ensures that the byte length of the data block is also a power of 2. Therefore, in step S32, subtracting one from the device species number and multiplying by the block length can be replaced by a shift operation instead of a multiplication operation. Furthermore, aligning the starting address of each data block to a power of 2 facilitates memory copying and moving the entire segment with aligned addresses. The address alignment granularity for the microcontroller to perform one memory transfer is sixty-four bytes; therefore, the alignment boundary is sixty-four bytes. The number of registers occupied by valid data fields in the read-only telemetry area or read-write control area for all device types is counted. The maximum number of valid data field registers for all device types is converted into bytes. This is added to the reserved bytes required for subsequent function iterations to add fields. The result is aligned upwards to the alignment boundary to obtain the byte length of the data block. The byte length of the data block is divided by the two bytes occupied by each register to obtain the block length, which is the number of registers occupied by the data block. The number of reserved bytes is no less than two bytes occupied by one register, and the sum of the maximum number of valid data field bytes and the number of reserved bytes, after being aligned upwards to the alignment boundary, is exactly equal to the byte length of the data block. The front of each fixed-length data block is the valid data field area, used to carry the actual data fields such as voltage, current, positioning or switch, brightness, and color of that device type. The rear is the reserved verification area. Since the byte length of the data block is no less than the maximum number of valid field bytes for all device types plus the number of reserved bytes, the number of bytes occupied by the reserved verification area of ​​each fixed-length data block is always no less than one register, i.e., two bytes, and the reserved verification area is not empty. The gateway-side shadow structure and the node-side structure define the types, order, and byte lengths of the valid data fields for each device species, collectively referred to as the field boundary definitions for that device species. When a device species needs to add new data fields during a functional iteration, the required bytes are allocated from the front of the reserved verification area as the new valid data field. The starting address, arrangement order, and block length of the existing valid data fields remain unchanged, and the addressing of other device species is unaffected. After the allocation, the reserved starting offset of that device species is shifted accordingly. The allocated portion is simultaneously incorporated into the field boundary definitions at both the gateway and node ends and used as a valid data field to carry data. The reserved verification area shrinks to the remaining portion and continues to be filled by the node with a reserved reference constant as a protected area for structural alignment verification.Therefore, the reserved verification area serves as both an extension reserve for subsequent fields and a protected area for structural alignment verification: the portion that has not yet been delineated is always filled with reserved baseline constants for structural alignment verification comparison, while the portion that has been delineated and synchronously incorporated into the field boundary definitions at both ends is considered a valid data field; the field boundary definitions at both ends must be updated synchronously. If only the node end is updated and the gateway end is not updated, the non-zero bytes of the newly added field will fall into the range that the gateway end still considers as a protected area, and the structural alignment verification will determine it as a structural mismatch and trigger a reread handshake, which in turn prompts the field boundary definitions at both ends to be synchronized. For example, the maximum number of valid data field registers is 14 registers, or 28 bytes, in the photovoltaic tile read / write control area. After adding the reserved bytes, it is aligned upwards to the alignment boundary of 64 bytes, resulting in a data block length of 64 bytes. Dividing 64 bytes by the two bytes occupied by each register, the block length is 32 registers. For the data block of the photovoltaic tile read / write control area, the master switch, hue, saturation, brightness, and special effects mode each occupy one register. Each of the five pulse width modulation channels occupies one register, for a total of five registers. The aforementioned fields occupy a total of ten registers. The two millisecond timing fields each occupy two registers, for a total of four registers. The valid data fields total 14 registers, or 28 bytes. The remaining 28 bytes to 64 bytes are reserved for verification.

[0060] Reference Figure 4 The diagram illustrates the principle of homomorphic memory mapping.

[0061] Figure 4 This demonstrates that both the gateway-side shadow structure and the node-side structure are arranged with single-byte alignment and consistent binary byte order, enabling the ModBus payload to be transported in its entirety via memory copy without the need for item-by-item shifting, splicing, or type conversion. The diagram shows that the node-side structure and the gateway-side shadow structure use the same structure definition, with identical field types, field order, and field byte lengths. The absence of padding bytes between fields indicates single-byte alignment, showing that the structure fields are arranged adjacently in memory according to their declaration order, and their binary byte order corresponds one-to-one with the byte order of the consecutive ModBus register addresses. The identical byte-by-byte binary arrangement of the structures at both ends indicates byte-by-byte homomorphism in the memory layout; the little-endian byte order markings on both microcontrollers indicate consistent binary byte order, demonstrating that the ModBus payload is transported between the two ends as a raw byte stream without the need for big-endian / little-endian conversion at the ModBus register level. The four or eight bytes of the floating-point field moved from the node to the gateway via the memory copy arrow represent telemetry data in IEEE-754 floating-point format. This indicates that the microcontroller can obtain the IEEE-754 floating-point number by reading this field, and the restoration operation is reduced to the overhead of one memory transfer.

[0062] Step S13: Make the shadow structure of the gateway end and the structure of the node end both arranged in single-byte alignment and with consistent binary byte order, and output the unified memory mapping.

[0063] Both the gateway's shadow structure and the node's structure are arranged with single-byte alignment. Single-byte alignment means that the compiler is forced to not insert any padding bytes between fields when the structure is declared, so that the fields of the structure are arranged adjacently in memory according to the order of declaration. The binary byte order of the structure in memory corresponds one-to-one with the byte order of the ModBus contiguous register addresses. The gateway's shadow structure and the node's structure use the same structure definition, and the field types, field order, and field byte lengths are completely identical. The binary arrangement of the structures at both ends in memory is thus identical byte-by-byte, resulting in a unified memory mapping. The consistent binary byte order means that the gateway and the node use the same byte order. In this embodiment, the microcontrollers at both the gateway and the node use little-endian byte order. Since the ModBus payload is copied and transported between the two ends in whole segments through memory as raw bytes without interpreting the byte order of the registers individually, the two ends only need to have consistent byte order to ensure that the memory layout is homomorphic byte-by-byte, without the need for big-endian-little-endian conversion at the ModBus register level. The unified memory mapping output in step S10 is used in step S20 to locate data blocks in the address grid in combination with the device species number read during runtime, and is used in step S30 to calculate the control area base address based on the block length.

[0064] In lighting environments where photovoltaic paving stones, streetlights, and downlights coexist, a single gateway must maintain register data for multiple types of devices in parallel. The ModBus register is inherently a linearly addressed space. As long as the base address and block length are fixed, the address of any field for any device species can be uniquely determined by the base address plus the offset within the block. Adding a field will not affect existing field addresses as long as it falls within the reserved check area. Based on this linear addressing principle, this step divides the address space into three segments according to a fixed base address and allocates equal-length data blocks to each device species. If a separate address table for each device is used, the old table addresses are squeezed out and fields are shifted when a new device is added, preventing new and old devices from sharing the acquisition program. A fixed base address plus equal-length blocks ensures that the field addresses of each device species remain anchored in a multi-species mixed environment.

[0065] Unified memory mapping ensures that register mirrors of different device species fall within an address grid defined by a fixed base address and block length. The addresses of fields with the same name remain constant across device species. When a new device species is added or a field is appended to an existing one, the block length and the starting address of existing fields remain unchanged, and addressing of other device species is unaffected. The underlying core source code for gateway telemetry and control does not need to be rewritten to adapt to new devices; only the field boundary definitions of the newly added or iterated device species (which are configuration data, not core processing logic) need to be updated synchronously at the gateway. Heterogeneous device access and firmware iteration no longer cause address misalignment of existing fields. After the three segments are physically isolated by address range, the target register address of any write instruction is limited to the read / write control area. Data acquired in the read-only telemetry area cannot be overwritten by control instructions, preventing accidental writing of acquired data at the addressing level.

[0066] Step S20: Poll the target node according to the unified memory mapping, read the general network identity area of ​​the target node to obtain the device species number, extract the ModBus payload from the return frame of the target node and verify it, perform structural alignment verification on the ModBus payload that passes the verification, and then copy it into the data block corresponding to the device species number in the device shadow pool to restore the telemetry data.

[0067] Step S20 polls the target node according to the unified memory mapping. This means that the gateway initiates bus transmission and reception sequentially for each node already archived in the device shadow pool according to the address grid determined by the unified memory mapping. The gateway first locates the target node's image according to the node index in the device shadow pool, and then calculates the register address of each area of ​​the target node according to the fixed base address and block length of the general network identity area and read-only telemetry area in the unified memory mapping. Based on this address, a ModBus read instruction is issued, thereby completing one polling of the target node. Step S20 includes steps S21, S22, S23, and S24. These four sub-steps sequentially complete polling and online determination, return frame stripping verification, structure alignment verification, and memory copy restoration, restoring telemetry data consistent with the actual measured value of the node on each polled target node.

[0068] Step S21: Read the online status of the target node in the device shadow pool: if it is unknown or offline, enter the identity detection mode, and only issue the instruction to read the general network identity area to obtain the device species number and update the online status; if it is online, enter the telemetry reading mode, select the address range to be read in this round according to the device species number and the polling beat count of each sensor, and issue the instruction to read the address range to be read in this round.

[0069] Retrieve the online status field of the target node in the device shadow pool. The online status is a field within the mirror of each node in the device shadow pool, with a value of either zero or one. Zero indicates the node is unknown or offline, while one indicates the node is online. Unknown and offline states are logically equivalent, both represented by a zero value in the online status field and uniformly entering identity detection mode. The online status determination condition is: read the online status field; if the field value is zero, the target node is determined to be unknown or offline, and identity detection mode is entered; if the field value is one, the target node is determined to be online, and telemetry reading mode is entered. The online status update rule is: when a node responds to an identity detection command and the response passes the verification in step S22, the online status field is set to one; when the number of consecutive failures to receive a valid response within the timeout period for a given node reaches the consecutive failure threshold, the online status field is set to zero. The continuous failure threshold is determined as follows: First, the single-transmission packet loss rate of the link under the target deployment scenario is measured. The single-transmission packet loss rate of the link is measured by continuously sending no less than one hundred read commands to the target node under normal working load of the target deployment scenario, and counting the ratio of the number of times a valid response is not received within the timeout period to the total number of transmissions. Then, an acceptable upper limit for the false offline probability is set, both of which are probability values ​​greater than zero and less than one. The continuous failure threshold is taken as the smallest positive integer that makes the integer power of the link packet loss rate less than the upper limit of the acceptable false offline probability. Its value is the result of dividing the natural logarithm of the upper limit of the acceptable false offline probability by the natural logarithm of the link packet loss rate and rounding up. Since both the link packet loss rate and the upper limit of the acceptable false offline probability are less than one, and their natural logarithms are both negative, the quotient of the two negative values ​​is positive, and the positive integer is obtained by rounding up. This value ensures that occasional continuous packet loss will not be falsely judged as node offline, while the node can be identified within a limited number of attempts when it is truly offline.

[0070] In identity detection mode, the gateway only sends a ModBus read instruction to the target node to read the first two registers from the base address in the general network identity area. After reading back, it retrieves the device species number from the general network identity area at a register offset from the base address (i.e., register address 1001). The device species number refers to the device species operating value read from the target node's general network identity area during operation, and is an unsigned integer. Photovoltaic paving tiles correspond to device species number one, streetlights correspond to device species number two, and downlights correspond to device species number three. The device species number corresponds to the device species determined in the design phase as described in step S12, with the former being the specific value of the latter during operation. After obtaining the device species number, the online status is updated according to the online status update rules.

[0071] In telemetry read mode, the gateway selects the address range to be read in the current round based on the device species number and the polling clock count of each sensor. A sensor data block refers to a continuous register range within the effective data field area of ​​a fixed-length data block, grouped according to the physical quantities measured by the same sensor. The continuous registers occupied by each sensor's measured physical quantity within the effective data field area constitute a sensor data block. The effective data field area of ​​the same fixed-length data block is divided into one or more sensor data blocks based on the type of sensor it carries. The polling clock count is a 16-bit unsigned integer count maintained by each sensor data block in the device's shadow pool. Each time the gateway completes a round of telemetry reads for a node, it increments the polling clock count of each sensor data block under that node's name by one. Each sensor data block is also configured with a polling clock threshold. The polling cycle threshold is determined as follows: For each physical quantity measured by a sensor, its allowable data staleness limit is determined, which is the upper limit of the allowable delay between the change in the physical quantity and the gateway's requirement to know about the change. The data staleness limit is determined as follows: First, the reporting resolution of the physical quantity is set, which is the minimum change in the physical quantity that the upper-layer application is required to distinguish. Then, under normal operating conditions of the target deployment scenario, the physical quantity is continuously sampled at a sampling rate no lower than the highest polling frequency in the telemetry reading mode. The absolute change in the value of the physical quantity between adjacent sampling times is recorded. The time span required for the cumulative absolute change in the value to reach a reporting resolution is calculated, and the data within the observation window is taken. The minimum value of this time span is used as the data aging time limit, ensuring that the gateway completes at least one data acquisition within the data aging time limit without missing any changes when the physical quantity undergoes a change that reaches the reporting resolution. The shorter the data aging time limit, the more drastic the change in the physical quantity per unit time, and the more frequent the data acquisition is required. Divide the data aging time limit by the time required to complete one round of basic polling and round down to obtain the polling cycle threshold of the sensor. If the result after rounding down is less than one, then take one. If the result is less than one, it means that the data aging time limit of the sensor is shorter than the time of one round of basic polling. Each round reads the corresponding highest achievable polling frequency, so one is taken as the cap value to collect sensor data at the maximum frequency. For example, electrical quantities such as voltage, current, and power change rapidly, and the shortest time required to reach a reporting resolution is equivalent to the duration of one round of basic polling. Therefore, their polling cycle threshold is taken as the minimum value of one, meaning that a reading is performed in each round. Physical quantities such as temperature and location change slowly, and the shortest time required to reach a reporting resolution is an integer multiple of the duration of one round of basic polling. Based on the above calculation method, their polling cycle threshold is taken as an integer greater than one obtained by dividing the above values ​​and rounding down.The selection method for the address range to be read in this round is as follows: traverse all sensor data blocks under the node name, and determine that any sensor data block whose polling tick count is not less than its own polling tick threshold is expired. The register address range occupied by the expired sensor data block is taken to form the address range to be read in this round. When the register address ranges of each expired sensor data block are consecutively adjacent in the read-only telemetry area, they are merged into a single ModBus read instruction for reading at once. When the register address ranges of each expired sensor data block are not consecutive, the gateway issues an independent ModBus read instruction for each expired sensor data block. The number of data blocks contained in the address range to be read in this round is counted according to the number of expired sensor data blocks actually participating in this round of reading. The gateway issues a ModBus read instruction to read the address range to be read in this round, and after reading back, the polling tick count of the read sensor data block is cleared to zero. Furthermore, to ensure that the structural alignment verification in step S23 has bytes in the reserved verification area available for comparison in each round of telemetry reading, the address range to be read in this round, in addition to the aforementioned expired sensor data blocks, is always merged into the reserved verification area of ​​the fixed-length data blocks involved: when the reserved verification area is continuous with the register address of an adjacent expired sensor data block, it is read back once by the same ModBus read instruction; otherwise, the gateway issues a separate independent ModBus read instruction. The structural alignment verification is performed on the read-back payload bytes that fall within the reserved verification area. Only after the structural alignment verification of the data block passes is the payload of each expired sensor data block under that data block allowed to be copied and written to memory in step S24. The readback of the reserved verification area is a fixed overhead of the structural alignment verification and is not included in the number of expired sensor data blocks constrained by the read budget. The address range to be read in this round selected in step S21 is used in step S22 to calculate the expected number of payload bytes to perform length verification, and in step S24 to determine the target byte range for memory copying within the corresponding data block; the device species number obtained in step S21 is used in step S24 to locate the corresponding fixed-length data block.

[0072] Whether a node is online is a binary fact that can be directly read from the online status field. Based on this binary fact, the processing is divided into two paths: identity detection and telemetry reading. This avoids wasting bus bandwidth by reading all sensors of offline nodes. The physical quantities of each sensor change at different rates. By comparing the polling tick count with the polling tick threshold, faster-changing quantities are read more, and slower-changing quantities are read less. If all sensors are polled at the same frequency, slower variables are repeatedly read without being read, crowding out the reading slots for faster variables. This step uses a dual-mode path and frequency division counting to ensure that bus readings only occur at necessary nodes and expired sensors.

[0073] Nodes with an online status of zero are only read from the general network identity area. The gateway completes the filing and updates the online status based on the read device species number. For nodes that are not yet online or are offline, no further reading of all their sensors is initiated, and the bus bandwidth is not consumed by the idle reading of offline nodes. Online nodes read only the expired sensor data blocks by comparing the polling tick count with the polling tick threshold. Fast-changing electrical quantities are refreshed every round, while slow-changing quantities are refreshed at integer multiples of the cycle. The effective telemetry update volume carried by the same bus bandwidth is increased accordingly, and the telemetry data acquisition throughput is not slowed down by the idle reading of slow variables when multiple nodes are connected.

[0074] Step S22: Receive the return frame from the target node. Based on the header, length field, and trailer of the return frame, use the length field as a pointer to locate and extract the clean ModBus payload and source node address. Then, verify the source node address, length, CRC, and function code in sequence. The length verification is performed by comparing the number of extracted ModBus payload bytes with the expected number of payload bytes calculated based on the number of registers contained in the address range to be read in this round as described in step S21, to obtain the ModBus payload that has passed the verification.

[0075] The return frame from the target node is retrieved from the receive message queue of the physical serial port. This return frame is transmitted back via the wireless mesh link and received by the gateway's physical serial port, then placed into the receive message queue. The return frame is a sequence of bytes with the following structure: a two-byte header at the beginning of the frame, followed by a one-byte length field, then the data area carrying the source node address and ModBus payload, and finally a two-byte trailer. The header uses a fixed byte sequence of 0xF1 and 0xDD, the trailer uses a fixed byte sequence of 0x0D and 0x0A, and the length field records the number of bytes in the data area. The method for extracting the pure ModBus payload and source node address is pointer-based location: Starting from the beginning of the return frame, the header byte sequence 0xF1, 0xDD is retrieved. After locating the header, the value of the length field is read. This value is used as the step size, and the data area is traversed forward by the specified number of bytes in the length field. The two bytes at the end of the traversal are checked to see if they match the packet tail byte sequence 0x0D, 0x0A. If the end of the traversal is the packet tail, the data area is determined to be a complete frame's data area. The source node address and ModBus payload are then extracted from the data area according to the agreed-upon field positions. The reason for using the length field as a pointer instead of sequentially searching for the packet tail is that the service bytes in the ModBus payload may exactly equal 0x0D, 0x0A, forming a pseudo-packet tail. Sequential searching would prematurely truncate the packet at the pseudo-packet tail. By directly traversing using the number of bytes recorded in the length field, pseudo-packet tail bytes are skipped during the traversal, and only the packet tail at the end of the traversal is checked, thus preventing false truncation caused by pseudo-packet tails.

[0076] After extracting the source node address and ModBus payload, four checks are performed sequentially. Source node address check: The extracted source node address is compared with the target node address of the current call. If they are not equal, it is considered a crosstalk frame and discarded; otherwise, it passes. Length check: The number of bytes in the extracted ModBus payload is compared with the expected payload byte number corresponding to the read instruction sent in the current round. The expected payload byte number is the product of the number of registers covered by the read instruction corresponding to the returned frame in the address range selected in step S21 and two bytes per register. If the former is less than the latter, it is considered a fragmented frame; if the former is greater than the latter, it is considered an over-length frame and discarded. If the former and the latter are equal, it passes. CRC check: The ModBus payload is calculated using the high-low bit lookup table method of ModBus cyclic redundancy check. The calculated check code is compared bit-by-bit with the check code carried in the returned frame in the same byte order. If any bit is different, it is considered an erroneous frame and discarded; otherwise, it passes. Function code verification: The function code carried in the return frame is compared with the function code of the instruction issued in this round. If they do not match, the function code is discarded; otherwise, the function code passes. After all four verifications pass, the verified ModBus payload is output for structural alignment verification in step S23.

[0077] The returned frame is transmitted via the Mesh link and may contain crosstalk frames and bit errors. The frame length is explicitly recorded in the length field. By using the length field, the pseudo-tail bytes in the payload can be traversed in one step, and delimitation no longer depends on the sequential retrieval of the tail bytes. If delimitation is based solely on the sequential retrieval of the header and tail bytes, the pseudo-tail bytes in the payload will cause the frame to be prematurely truncated, resulting in the loss of subsequent bytes. The source node address, length, checksum, and function code are all fields that can be directly extracted from the returned frame and compared item by item. The comparison of these four items prevents crosstalk frames, fragmented frames, bit error frames, and frames with incorrect function codes from being detected before the structural alignment check, providing a transport layer error-free ModBus payload for step S23.

[0078] Reference Figure 5 The diagram shows a schematic of the alignment verification of the structure.

[0079] Figure 5This diagram illustrates the process of byte-by-byte summation of validated ModBus loads within the reserved check area to obtain a structural alignment check value, which is then compared with the expected value to determine whether the structures at both ends are homomorphic. The diagram shows an ordered sequence of integers representing field offsets, arranged by prefix sums of the field boundaries of a fixed-length data block. The last segment of this sequence, from the reserved starting offset to the length of the data block, represents the reserved check area, indicating that this area is filled byte-by-byte by nodes using the reserved baseline constant 0x00. The diagram also shows a single scalar representing the structural alignment check value, obtained by byte-by-byte summation of the reserved check area. When the field layout of the sending end in the upper part of the diagram is aligned byte-by-byte with the shadow structure of the gateway end, all bytes in the reserved check area are 0x00, and the sum equals the expected value of zero. This indicates that the structure alignment check value is equal to the expected value, indicating that the structures at both ends are determined to be homomorphic and the memory copy in step S24 is allowed. When the node firmware inserts a field, misjudges the species number, or reassembles a broken frame, causing the bytes to shift as a whole, the non-zero bytes that were originally valid data fields are moved into the reserved check area, and the sum deviates from the expected value. This indicates that the structure alignment check value is not equal to the expected value, indicating that the structure is determined to be mismatched, penetration is rejected, and a re-read handshake for the target node firmware version is triggered. The structure alignment check in the diagram intercepts layout shift errors like the one shown, which move non-zero bytes into the reserved check area, pass CRC check but do not match the actual physical quantity. This shows that it exposes field layout shifts that the transport layer CRC cannot detect at the numerical level.

[0080] Step S23: Perform the structural alignment check on the ModBus load that has passed the check, and obtain the structural alignment check value; Step S23 includes steps S231, S232 and S233.

[0081] Step S231: The field offset sequence is formed by arranging the field boundaries of the fixed-length data block according to the prefix sum. The reserved verification area is determined by the last segment of the field offset sequence. The reserved verification area is filled by nodes with reserved reference constants.

[0082] The field offset sequence is formed by arranging the field boundaries of a fixed-length data block according to their prefix sums. The field offset sequence is an ordered sequence of integers, where each element represents the byte offset of a field boundary within the data block relative to the start of the data block. The first element of the sequence is zero, representing the starting boundary of the first valid data field; the second element equals the byte length of the first valid data field, representing the ending boundary of the first valid data field, which is also the starting boundary of the second valid data field; the k-th element equals the sum of the byte lengths of the k-th and one-first fields preceding it; the element corresponding to the ending boundary of the last valid data field equals the sum of the byte lengths of all valid data fields, denoted as the reserved starting offset; the last element is the byte length of the data block, representing the ending boundary of the data block. The final segment of the field offset sequence, i.e., the byte interval from the reserved starting offset to the byte length of the data block, is defined as the reserved check area. Each element of the field offset sequence is an unsigned integer in terms of data type, and its value is obtained by summing the prefix sums of the byte lengths of each valid data field determined for this device species in step S12. The first elements of the field offset sequence are intermediate accumulated values ​​obtained by summing the prefix sums item by item to calculate the reserved starting offset. The element accumulated to the end boundary of the last valid data field gives the reserved starting offset, and the element accumulated to the last element gives the byte length of the data block. Based on the reserved starting offset and the byte length of the data block, the last segment is determined as the reserved check area, which is used by step S232 to calculate the sum within this segment. The reserved check area is defined by the node writing a reserved reference constant to each byte of this segment when filling the data block. The reserved reference constant is a fixed value given by the configuration, and the gateway and all nodes are consistent with it, taking 0x00. The reason for taking 0x00 is that a zero value makes each byte of the reserved check area zero during structural alignment, and the accumulated sum is always zero, which facilitates comparison. Moreover, structural mismatch will cause the accumulated sum to deviate from zero when non-zero valid data bytes are moved into this segment, thus exposing the mismatch.

[0083] Step S231 arranges the field offset sequence using prefix sums and defines the reserved verification area based on its last segment. The physical mechanism is as follows: structural alignment verification requires comparison on a byte interval with known content at both ends. The position of this interval varies depending on the device species, and the number and byte length of valid data fields differ for each device species. The starting point of the reserved verification area is equal to the sum of the byte lengths of all valid data fields for that device species. Only by accumulating the byte lengths of each field using prefix sums can this starting point be calculated, thus defining the reserved verification area. By automatically calculating the interval boundary using prefix sums instead of hard-coding a fixed interval for each device species, the same verification logic does not need to be rewritten with the addition or deletion of device species. The reserved verification area for any device species is calculated from its own field layout. Furthermore, this interval is uniformly filled by nodes using reserved baseline constants, and its agreed-upon content is known. This provides a definite and known comparison baseline for step S232 to calculate the cumulative sum within this interval and for step S233 to compare the structural alignment status using the cumulative sum.

[0084] Step S232: Calculate the sum byte by byte for the ModBus load that has passed the verification within the reserved verification area to obtain the structure alignment verification value.

[0085] For the ModBus loads that pass the verification, the structural alignment verification value is obtained by summing the values ​​byte by byte within the reserved verification area. The structural alignment verification value is equal to the arithmetic sum of the values ​​of each byte within the reserved verification area, and is an unsigned integer ranging from zero to 255 multiplied by the number of bytes in the reserved verification area. Since step S12 ensures that the number of bytes in the reserved verification area of ​​each fixed-length data block is not less than two bytes, the summation object contains at least two bytes, and there is no situation where the summation of an empty set degenerates into an undefined value.

[0086] The physical meaning of the structure alignment check value is the total deviation of all bytes within the reserved check area from the reserved reference constant: when the structures at both ends are aligned byte by byte, each byte in this area is the reserved reference constant 0x00 written by the node, and the sum is zero. When the structure mismatch causes the non-zero bytes of the original valid data fields to shift into this area, the sum deviates from zero accordingly. Therefore, the structure alignment check value, as a single scalar, encapsulates the structure alignment state of whether the entire reserved check area is still the reserved reference constant. The reason for using the single scalar of the sum instead of comparing each byte of the area is that, under the premise that the reserved reference constant is 0x00 and each byte is an unsigned integer, a sum of zero is equivalent to each byte in the area being equal to 0x00. A single traversal and accumulation can compress the alignment state of the area into a scalar that can be directly compared with the expected value. Its comparison cost is proportional to the number of bytes in the area and is independent of the number of fields. Its beneficial effect is that it provides a verification quantity for step S233 that can both characterize the structural alignment state and facilitate the determination in one comparison, so that the field layout shift that the transport layer CRC cannot detect can be exposed at the numerical level.

[0087] Step S233: Compare the structure alignment check value with the expected value corresponding to the reserved reference constant. If they match, determine that the structures at both ends are homomorphic and allow the memory copy in S24. If they do not match, determine that the structure is mismatched, refuse penetration, and trigger the reread handshake.

[0088] The structural alignment check value is compared with the expected value corresponding to the reserved baseline constant. The expected value corresponding to the reserved baseline constant is equal to the product of the single-byte value of the reserved baseline constant and the number of bytes in the reserved check area; when the reserved baseline constant is 0x00, the expected value is zero. Since the reserved baseline constant is 0x00, each byte in the reserved check area is an unsigned integer, and the sum of the bytes is zero, which is equivalent to each byte in the area being equal to the reserved baseline constant. When the value is 0x00, the summation is used instead of the byte-by-byte comparison to avoid missing detections. Both the structural alignment check value and the expected value are unsigned integers obtained byte-by-byte within the same reserved check area, and their values ​​range from zero to 255 times the number of bytes in the area. They have the same physical meaning as the sum of the byte values ​​in the area, have the same dimensions, and their numerical ranges overlap, so they can be directly compared. The comparison criteria are as follows: when the structural alignment check value equals the expected value, the structures at both ends are determined to be homomorphic, and the memory copy in step S24 is allowed; when the structural alignment check value does not equal the expected value, a structural mismatch is determined, penetration is rejected, and a re-read handshake for the firmware version of the target node is triggered. The boundary case where the structural alignment check value exactly equals the expected value is classified as being on the homomorphic side and is allowed.

[0089] As long as the field layout of the sending end is aligned byte-by-byte with the shadow structure of the gateway end, the bytes falling within the reserved verification area can only be the reserved baseline constant written by the node, and the sum will always equal the expected value. However, if the node firmware inserts a field, misjudges the species number, or reassembles a broken frame, causing the bytes to shift as a whole, and the bytes shifted into the reserved verification area contain non-zero bytes, the sum will deviate from the expected value. It should be noted that when the shift causes the bytes shifted into the reserved verification area to be exactly zero, i.e., all equal to the reserved baseline constant 0x00, the sum still equals the expected value, and this shift is not detected by this verification, which is an acceptable residual missed detection probability. Since the reserved verification area consists of multiple bytes, the probability that the entire shifted byte segment is exactly zero decreases as the number of bytes in the area increases. If a direct memory copy is performed without structural alignment verification, the CRC only checks the transmitted bits and lets the layout shift pass through, and the error value will be silently written to the floating-point field. This step intercepts such layout shifts that move non-zero bytes before the memory copy by comparing the cumulative sum with the expected value, thereby significantly reducing the probability of layout shift error values ​​polluting the device shadow pool.

[0090] When the structure alignment check value equals the expected value, it indicates that the data block layout at the sending end is aligned byte-by-byte with the shadow structure at the gateway end. At this time, the allowed memory copy will move each byte into the corresponding floating-point field without field misalignment, and the restored telemetry data such as voltage, current, and positioning will be consistent with the actual measured values ​​of the node. When the structure alignment check value does not equal the expected value, penetration is rejected, and bytes carrying layout shifts are blocked from the floating-point field. When the layout shift causes non-zero bytes to move into the reserved check area, the accumulated sum deviates from the expected value, thus rejecting penetration. This intercepts such erroneous values ​​that can pass CRC but do not match the actual physical quantity, significantly reducing the probability of them polluting the device shadow pool. Thus, the zero-by-item parsing advantage of homomorphic memory mapping obtains runtime guarantee based on the premise of structure alignment during runtime, rather than relying solely on developer discipline based on field agreements during the development phase.

[0091] Step S24: When the structure alignment check value indicates that the structures at both ends are homomorphic, the ModBus payload is written into the data block corresponding to the device shadow pool and the device species number, and the target byte range corresponding to the address range to be read in this round, through the memory copy, to restore the telemetry data in IEEE-754 floating-point format and update the online status; when the structure alignment check value indicates that the structure is mismatched, the ModBus payload is discarded, the online status of the target node is set to zero and marked as structural mismatch, and a re-read handshake for the firmware version of the target node is triggered.

[0092] Based on the comparison result of step S233, the process is divided into two paths. When the structural alignment check value equals the expected value, i.e., the structures at both ends are homomorphic, the gateway calls the memory copy function to move the entire ModBus payload that has passed the check into the target byte range in the data block corresponding to the device species number in the device shadow pool. The memory copy function refers to a function that takes the source address, the target address, and the number of bytes to be copied as input parameters, and copies a continuous memory of a specified number of bytes from the source address to the target address byte by byte, without performing any numerical interpretation or format conversion on the content being copied during the copying process. For example, the memcpy function in the C standard library. The target byte range is located as follows: First, the device species to which the node belongs in the read-only telemetry area is determined by the device species number. Then, the target data block is determined according to the starting address of the fixed-length data block allocated to the device species in step S12. Next, the starting point and number of bytes of the target byte range are determined within the fixed-length data block according to the address range covered by the read instruction corresponding to the ModBus payload in the current round of the address range to be read selected in step S21. The target address of the memory copy function is taken as the starting point of the target byte range, and the number of bytes copied is taken as the product of the number of registers covered by the read instruction and two bytes per register. When the current round of the address range to be read is covered by multiple read instructions, the return frames of each read instruction are processed by steps S22 to S24 respectively, and each is moved into the target byte range corresponding to the address range it covers. Since step S13 has ensured that the structures at both ends are aligned to single bytes and arranged identically byte-by-byte in binary, the four or eight bytes in IEEE-754 floating-point format carried in the ModBus payload are copied verbatim into the corresponding single-precision or double-precision floating-point field in the shadow structure. The microcontroller reads this field to obtain the IEEE-754 floating-point number without the need for item-by-item shifting, splicing, or type conversion, thus restoring the telemetry data. Subsequently, the online status field is set to one according to the online status update rules. When the structure alignment check value is not equal to the expected value, i.e., when there is a structure mismatch, the gateway discards the ModBus payload, does not perform a memory copy, sets the online status field of the target node in the device shadow pool to zero and marks it as a structure mismatch, and triggers a re-read handshake for the firmware version of the target node. The reason for triggering the reread handshake is that the structural mismatch is due to the change in field layout caused by the node firmware iteration. It is necessary to reread the device species number and firmware version fields in the node's general network identity area to confirm whether the layout has changed. After setting the online status field to zero, in the next round of reading the node's online status, step S21 causes the node to re-enter the identity detection mode, reread the general network identity area, and reconfirm the device species number and firmware version because its value is zero.After reconfirmation, two scenarios are handled: First, if the firmware version read back is consistent with the version corresponding to the field boundary definition currently saved by the gateway for the species of this device, it indicates that the field layout has not changed, and the mismatch is caused by transient reasons such as multiple frame breaks and reassemblies or species misjudgment. After setting the online status field to one according to the online status update rules, subsequent telemetry readings are allowed, and the structure alignment verification of the next round of telemetry readings will be restored to pass. If the number of times the reread handshake is triggered for the same node and the structure alignment verification still fails reaches the continuous failure threshold, it indicates that it is not a transient reason. Then, the node is marked as having an unknown layout and telemetry readings for it are suspended. Secondly, the read-back firmware version has changed, indicating that the field layout of this device species has changed with firmware iterations. The gateway first updates the field boundary definitions saved for this device species on its side to the new definitions corresponding to the firmware version. This update is an update to the configuration data of the field boundary definitions on the gateway side, rather than a rewrite of the core processing logic. After the update, the gateway recalculates the reserved starting point offset and the reserved verification area according to the new field boundary definitions in step S231. After the structure alignment verification passes again, the online status field is set to one according to the online status update rules, and telemetry reading of this node is resumed. Before the gateway completes the synchronous update of the field boundary definitions, the node is marked as having an unknown layout and telemetry reading of it is suspended. The above processing avoids repeatedly writing translation bytes into the floating-point field before the layout is clarified. The telemetry data restored in step S24 is written to the corresponding data block in the device shadow pool for scheduling reading and incremental reporting reading in step S30 during polling intervals.

[0093] In step S20, step S21 uses the binary facts of the online status field to branch the processing into two paths: identity detection and telemetry reading. It selects the address range to be read in the current round by comparing the polling tick count and the polling tick threshold, so that bus reading only occurs on necessary nodes and expired sensors. In step S22, the length field is used as a pointer to strip out the pure ModBus payload, and cross-platform frames, fragmented frames, bit error frames, and incorrect function code frames are filtered out by four checks: source node address, length, CRC, and function code. In step S23, the structure alignment is checked by summing in the reserved check area to intercept layout translation errors that can pass the CRC but do not match the actual physical quantity. In step S24, when the structure alignment premise is met, the ModBus payload is copied into the corresponding field of the shadow structure to restore the IEEE-754 floating-point format telemetry data. When the structure is mismatched, the payload is discarded, the online status is set to zero, and a reread handshake is triggered. Step S20, relying on the unified memory mapping output in step S10, transforms the restoration of the binary byte stream returned by the bus from field-by-field shifting and splicing to a complete memory copy. This reduces the computational resources required to restore high-precision data to the overhead of a single memory transfer. The throughput of telemetry data acquisition is no longer slowed down by field-by-field parsing when multiple nodes are connected. At the same time, structural alignment verification sets a runtime structural homomorphic premise for the complete memory copy, so that the zero-item-by-item parsing advantage of homomorphic memory mapping no longer depends solely on the field conventions during the development phase, but obtains structural alignment verification guarantee at runtime. When layout shifting causes non-zero bytes to move into the reserved verification area, it is intercepted, significantly reducing the probability that layout shifting caused by node firmware iteration, species misjudgment, or frame reassembly will silently write incorrect values ​​into floating-point fields.

[0094] Step S30: Write the control command issued by the human-machine interface or cloud along with the target register address into the control command queue. Detect the control command queue during the intervals of the polling. If there is a control command to be processed, calculate the control area base address based on the device species number and the block length, verify the target register address, and then issue a write command to the target node. After processing is completed, resume the polling.

[0095] Step S30's task is to establish a low-latency transmission path for control commands suddenly issued by the human-machine interface or cloud, outside of the telemetry polling in step S20, without waiting for the entire round of telemetry readings to finish. Control commands are transmitted to the target node during the intervals between telemetry polling sessions, and polling resumes after processing. Step S30 includes steps S31, S32, and S33, which sequentially complete the generation of control commands, queuing and address verification, and transmission during polling intervals, enabling sudden control commands to be issued during polling intervals without waiting for the entire round of telemetry readings to finish.

[0096] Step S31: Receive operations from the human-machine interface control or the cloud. Since the data flow identifier of the human-machine interface control is bound to the physical address of the ModBus register, the control instruction containing the target node identifier, the target register address and the control value is directly generated without going through the address translation table.

[0097] The system receives operations from human-machine interface (HMI) controls or cloud-based commands. The data flow identifier of each HMI control is bound one-to-one with the physical address of a ModBus register. This means that each HMI control is directly assigned the physical address of its target register during the design phase as its own data flow identifier. When a user performs on / off, dimming, or color adjustment on the HMI, the HMI control directly obtains the target register address based on its own data flow identifier, generating a control command containing the target node identifier, target register address, and control value, without address translation. For example, when a user drags the brightness slider of a photovoltaic floor tile, the data flow identifier of the brightness slider is the physical address 20483 of the brightness register. Based on this, the slider directly generates a control command containing the target node identifier, target register address 20483, and control value. Operations sent from the cloud are also received by the 4G communication module and similarly constitute control commands in the form of a target node identifier, target register address, and control value.

[0098] Reference Figure 6 The diagram shows an arithmetic progression addressing relationship.

[0099] Figure 6 This diagram illustrates how control blocks for each device species are arranged at equal intervals within the read / write control area, with the block length as the step size. The control area base address is calculated in one step using the device species number and block length according to an arithmetic progression. The diagram shows three equal-length control blocks arranged sequentially within the read / write control area with a block length step of 32, representing the control blocks for photovoltaic pavers, streetlights, and downlights respectively. This demonstrates that for each increment in the device species number, the starting point of the control block moves forward by one block length. The control area base address is equal to the sum of a constant 20480 and the device species number minus one multiplied by the block length: for the photovoltaic pavers (device species number one), the control area base address is 20480; for the streetlights (device species number two), it is 20512; and for the downlights (device species number three), it is 20544. This shows that the control area base address can be calculated in one step without looking up a table. The diagram shows a valid control block with the control area base address as the starting point and the length of the block as the block length. The target register address falling into this range indicates that the verification is passed and the block is allowed. The target register address that crosses the block boundary indicates that the block is out of bounds and the instruction is rejected. This means that the write instruction will not cross the block boundary and write to the control block of the adjacent device species.

[0100] Step S32: Write the control instruction into the control instruction queue in a non-blocking manner; establish an arithmetic addressing relationship, such that the control area base address is equal to the sum of 20480 and the device species number minus one, multiplied by the block length, and calculate the control area base address of the target node accordingly, and verify that the target register address falls into a valid control block with the control area base address as the starting point and the length of the block.

[0101] Control commands are written to the control command queue in a non-blocking manner. The control command queue is a first-in, first-out message queue, and each element is a fixed-length message containing the target node identifier, target register address, and control value. Writing in non-blocking mode means that the human-machine interface (HMI) interaction thread or the cloud receiving thread returns immediately after adding the control command to the queue, without waiting for it to be retrieved by the gateway. The HMI interaction thread is not blocked while waiting for the physical bus. After writing to the control command queue, an arithmetic progression addressing relationship is established to calculate the control area base address: the control area base address equals the sum of the constant 20480, the device species number minus one, and the block length. When the equipment species number is one (photovoltaic floor tile), the equipment species number is reduced by one to zero, and the control area base address equals 20480 plus the product of zero and the block length of 32, which is 20480. When the equipment species number is two (street lamp), the equipment species number is reduced by one to one, and the control area base address equals 20480 plus the product of one and the block length of 32, which is 20512. When the equipment species number is three (downlight), the equipment species number is reduced by one to two, and the control area base address equals 20480 plus the product of two and the block length of 32, which is 20544. The reason why it can be calculated in one step using an arithmetic progression without looking up a table is that the control blocks of each equipment species are arranged at equal intervals within the read / write control area with the block length as the step size. For each increase in the equipment species number, the starting point of the control block moves forward by one block length. After calculating the control area base address, the target register address is verified: if the target register address is not less than the control area base address and is less than the sum of the control area base address and the block length, the target register address is determined to fall into a valid control block with the control area base address as the starting point and the length being the block length, and the request is allowed; if the target register address is less than the control area base address or not less than the sum of the control area base address and the block length, the request is determined to be out of bounds and the request is rejected, to prevent the write instruction from crossing the block boundary and writing into the control block of an adjacent device species.

[0102] Step S33: Detect the control instruction queue during the interval of the polling. If it is not empty, suspend and save the current polling position, prioritize sending the write instruction to the control area register of the target node, and restore the saved current polling position after receiving an acknowledgment or timeout.

[0103] The control command queue is checked during the polling interval. The polling interval refers to the period between the completion of one bus transmission / reception cycle in telemetry read mode or identity detection mode and the initiation of the next bus transmission / reception cycle. When a non-empty control command queue is detected, indicating the presence of pending control commands, the current polling is suspended and the current polling position is saved. The current polling position consists of two parts: the node index of the next node to be polled, and the block number of the next data block to be read within the current address range of that node. These two parts together determine the starting point of the next bus transmission / reception cycle after polling resumes. Subsequently, a write command is first issued to the control area register of the target node. After receiving an acknowledgment from the target node or waiting for the timeout period to expire, the saved current polling position is restored, and telemetry polling continues. The timeout limit is determined as follows: In the target deployment scenario, multiple read or write commands are executed on the target node and the round-trip time from issuing the command to receiving the response is recorded. The maximum value of all round-trip times is taken as the timeout limit, so that normal responses are not prematurely judged as timeout and interrupted, and the bus can be relinquished and polling can resume within the timeout limit when the node does not respond.

[0104] The data flow identifiers of the HMI controls are directly taken as the physical addresses of the target registers during the design phase. The target register addresses carried by the control instructions are the underlying physical addresses, eliminating the need for address translation tables. The control blocks of each device species are arranged at equal intervals of block length within the read / write control area. Therefore, the base address of the control area can be calculated in one step from the device species number and the block length using an arithmetic progression. If two systems, HMI address and ModBus address, are used together with an address translation table, the translation table will expand as the number of device species increases, and burst instructions will only be issued after the entire round of polling has ended.

[0105] The target register address carried by the control command is the underlying physical address. After obtaining the device species number, the gateway calculates the control area base address in one step using an arithmetic progression and verifies whether the target register address falls into a valid control block. The command routing no longer goes through the address translation table that expands with the increase of devices. After the control command is written to the control command queue in a non-blocking manner, the human-machine interface interaction thread returns immediately without being stuck due to waiting for the physical bus. When the gateway detects that the control command queue is not empty during the polling interval, it suspends the current polling, saves the current polling position, and issues the write command first. After processing, it resumes the polling from the saved current polling position. Sudden control commands can be issued without waiting for the entire round of telemetry reading to finish, thus alleviating control lag and command congestion.

[0106] Furthermore, it also includes: when the target node switches from offline to online, the polling cycle count of each of its sensors is set to full so as to force full harvesting in the next cycle; and the number of data blocks contained in the address range to be read in this round selected by S21 decreases as the backlog depth of the control command queue increases in the previous cycle, so that the polling rounds of the telemetry reading mode and the backlog depth of the control command queue form a mutually restrictive closed loop.

[0107] When a target node transitions from offline to online (i.e., the online status field changes from zero to one), the gateway sets the polling tick count for each sensor data block under that node to full. "Full" means assigning the polling tick count the maximum value that its data type can represent, 0xFFFF (the maximum value that a 16-bit unsigned integer can represent). Since the full polling tick count of 0xFFFF is not less than the polling tick threshold of any sensor, all sensor data blocks under that node are deemed expired in the next round of telemetry reading after the transition, and the gateway forces a full harvest of all sensor data blocks from that node in the next cycle. The reason for setting the count to full immediately upon transitioning from offline to online, rather than increasing it incrementally as usual, is that when a node first comes online, the telemetry data for that node in the device's shadow pool is still empty. If counting is done using the usual frequency division, slow variable data blocks would take multiple rounds to expire, during which time the upper layer would read empty values, resulting in a cold start deadlock. Setting the count to full ensures that all data blocks are filled within one round after coming online, eliminating the cold start empty values.

[0108] When selecting the address range to be read in step S21, the number of data blocks it contains is constrained by the read budget. The read budget is determined as follows: first, the backlog depth of the control instruction queue in the previous cycle is compared with the read budget baseline value. When the backlog depth is less than the read budget baseline value, the read budget is the difference between the read budget baseline value and the backlog depth; when the backlog depth is not less than the read budget baseline value, the read budget is an integer. Here, a cycle refers to a complete traversal process in which the gateway polls all online nodes in the device shadow pool in turn. A cycle begins with the first bus transmission and reception of this complete traversal and ends with the last bus transmission and reception of this complete traversal. The backlog depth refers to the number of control instructions that have not yet been retrieved from the control instruction queue at the end of the previous cycle. The read budget baseline value is determined as follows: under the target deployment scenario, the round-trip time of one read bus transmission and reception to complete a data block is measured, as well as the maximum queuing delay of control instructions that the business can tolerate. The maximum queuing delay of control instructions that can tolerate is divided by the round-trip time to complete the read of a data block and rounded down to obtain the read budget baseline value. In the first cycle after the gateway starts, there is no previous cycle, so its backlog depth is set to zero, and the read budget is taken as the baseline value as the initialization value. The number of data blocks contained in the address range to be read in this round is the smaller of the number of expired sensor data blocks and the read budget. They are selected from the expired sensor data blocks in ascending order of register address. Expired data blocks not selected in this round are not cleared, and their polling tick count continues to increase with each round. In the next round, they will be selected first because their count is larger. The read budget decreases proportionally to the backlog depth in a one-to-one manner. Physically, this means that for every backlogged control command, one less telemetry data block is read in the current round, freeing up one bus transceiver slot for step S33 to issue the control command. This one-to-one decrease is based on the premise that the bus round-trip time for completing one read of a single data block is comparable in magnitude to the bus round-trip time for issuing a single control command. Under this premise, the bus transceiver slot freed up for each less read telemetry data block can accommodate approximately one control command issuance. Both the read budget reference value and the backlog depth are counted as unsigned integers and correspond one-to-one according to the aforementioned premise of comparable slots. Since the subtraction is only performed when the backlog depth is less than the read budget reference value, and the integer value is directly taken as one when the backlog depth is not less than the read budget reference value, the read budget is always not less than one, and underflow will not occur due to the unsigned integer subtraction when the backlog depth is greater than the read budget reference value, thus preventing read budget anomalies. When the backlog depth is not less than the read budget baseline value, the read budget is set to an integer value of 1 as the bottom line. In this round, one expired data block is still read. The handling of this conflict situation is classified as bottom line value 1: even if the backlog is extremely deep, the lower limit of reading one data block per round is maintained. Its acceptability lies in maintaining telemetry without complete interruption with the minimum telemetry read volume, while giving all remaining bus time slots to the control command issuance. If no bottom line is set and the read budget is reduced to zero, the telemetry read will completely stop during the backlog, which is contrary to the basic responsibility of telemetry acquisition. Therefore, bottom line value 1 is taken.

[0109] The physical bus can only complete a limited number of transmit and receive operations per unit of time. The more transmit and receive operations a round of telemetry occupies, the longer the round takes, and the later the gateway returns to the polling interval to check the control command queue. The deeper the backlog of the control command queue, the more burst commands are waiting to be issued. Based on this, the number of data blocks read in each round of telemetry reading mode decreases with the backlog depth of the control command queue in the previous cycle. The bus time slot occupied by telemetry in this round is then given up to control commands, allowing step S33 to drain the control command queue more quickly. If a fixed number of blocks is used for polling, the number of rounds will not shorten when high-concurrency commands flood in, and control commands will continue to accumulate until the queue overflows and is discarded.

[0110] The polling cycle count of each sensor is filled when the node switches from offline to online. The next round of telemetry reading mode harvests all sensor data blocks of the node at once. The telemetry data of the node in the device shadow pool is immediately filled after coming online, and the upper layer reading no longer encounters cold start deadlock caused by null values. The number of data blocks contained in the address range to be read in this round decreases with the backlog depth of the control command queue in the previous cycle. The deeper the backlog, the fewer bus time slots occupied by each round of telemetry and the shorter the polling rounds. Step S33 issues the backlogged control commands faster in the denser polling intervals, and the queue backlog is reduced. The polling rounds of the telemetry reading mode and the backlog depth of the control command queue are thus mutually causal and mutually restrictive. When high-concurrency control commands flood in, the physical bus will not be filled by long telemetry reads, causing control command congestion and loss.

[0111] Reference Figure 7 The diagram illustrates the incremental reporting process.

[0112] Figure 7This diagram illustrates the process of a gateway maintaining a change register bitmap covering a read-only telemetry zone, and generating incremental reporting messages only for consecutive address ranges that have changed after periodic scanning. The diagram shows a bitmap where the number of bits equals the number of registers in the read-only telemetry zone, and each bit corresponds one-to-one with a register in the read-only telemetry zone. The zeroth bit in the diagram corresponds to the register at base address 8192 in the read-only telemetry zone. Bits set to 1 when the value copied to memory differs from the original value in the device's shadow pool indicate that the corresponding register has changed value since the last report; bits set to zero indicate no change. During periodic scanning, the diagram shows traversing the bit positions from low to high, merging consecutively set bits into consecutive address ranges. This represents merging adjacent change registers into a single range report, with the starting address being the register address corresponding to the lowest bit and the ending address being the register address corresponding to the highest bit in that consecutive set bit range. The diagram shows that only the message generated from each consecutive address range obtained by merging represents the incremental reporting message. The register corresponding to the unset bit is not entered into the message, indicating that the message length transmitted between the end cloud increases with the actual change rather than the total amount of the read-only telemetry area. The diagram shows that after reporting, the entire bitmap of the change register is cleared to zero, indicating that the next cycle will be measured again based on the change.

[0113] Furthermore, it also includes: maintaining a change register bitmap covering the read-only telemetry area; setting the corresponding bit in the change register bitmap when the value copied to memory is different from the original value in the device shadow pool; periodically scanning the change register bitmap, merging consecutively set bits into consecutive address ranges, generating incremental reporting messages only for the consecutive address ranges, and clearing the change register bitmap after reporting.

[0114] The gateway maintains a change register bitmap covering the read-only telemetry area. The change register bitmap is a bit array with the number of bits equal to the number of registers contained in the read-only telemetry area. The i-th bit in the bitmap corresponds one-to-one with the register at address 8192 plus i in the read-only telemetry area, where i is an integer ranging from zero to the number of registers in the read-only telemetry area minus one. The zeroth bit corresponds to the register at the base address 8192 of the read-only telemetry area. A bit of 1 indicates that the corresponding register has changed in value since the last report, and a bit of 0 indicates that it has not changed. The bit setting rules are as follows: Before performing memory copying in step S24, the new value to be written is compared register by register with the original value of that register in the device shadow pool. During the comparison, the byte range corresponding to each register in the ModBus payload is determined by the base address of the read-only telemetry area and the register address. Bytes at the same offset position in the device shadow pool are compared byte by byte. For registers where the new value is different from the original value, the bit corresponding to that register in the changed register bitmap is set to one. When the data field across multiple registers changes, each register it occupies is independently compared and set at the register granularity. Adjacent set bits are merged into the same continuous address range and reported together during scanning. The gateway periodically scans the changed register bitmap according to the scan cycle. The scanning cycle is determined as follows: the scanning cycle is taken as the data staleness limit that the fastest changing telemetry data in the read-only telemetry area can tolerate in the cloud, so that the jump of the fastest changing telemetry data can be reported within its tolerable staleness limit. Here, the tolerable data staleness limit in the cloud is the time limit for telemetry data to be reported to the cloud from the device shadow pool, which is independent of the data staleness limit used to determine the polling tick threshold in step S21. The latter constrains the local polling frequency of the gateway reading from the node, and the former constrains the scanning frequency of the gateway reporting to the cloud. During scanning, consecutively set bits are grouped into consecutive address intervals: the changing register bitmap is traversed from low to high along the bit position, and all adjacent bits that are both set to 1 are grouped into the same consecutive address interval. The starting address of the consecutive address interval is the register address corresponding to the lowest bit in the consecutive set bits, and the ending address is the register address corresponding to the highest bit. When a zero bit appears between two adjacent set bits, the consecutive address interval is broken. Only for each consecutive address range obtained by merging, the current value of the corresponding register is retrieved from the device shadow pool to generate an incremental reporting message. Registers with unset bits are not included in the message. After reporting, the entire change register bitmap is cleared so that the next cycle is measured again based on the change.

[0115] During memory copy-write operations, the new value is compared with the original value register by register to directly determine whether the register has changed in the current cycle. Whether it has changed or not is a directly observable binary fact that can be recorded with a single bit. When adjacent registers change simultaneously, their addresses are continuous within the read-only telemetry area and can be expressed together using a continuous address range. If the entire read-only telemetry area is reported every cycle, unchanged fields are repeatedly transmitted, and the WAN bandwidth is constantly saturated. This mechanism only reports the continuous address ranges that have changed, so that the message length increases with the actual amount of change rather than the total amount of the read-only telemetry area.

[0116] The change register bitmap records the change status of each register in the read-only telemetry area with an overhead of one bit per register. During periodic scanning, consecutively set bits are merged into consecutive address intervals. Incremental reporting messages are generated only for consecutive address intervals that have changed. Unchanged registers are not included in the message. The message length transmitted between the end and the cloud increases with the actual change amount rather than the total amount of the read-only telemetry area. After consecutively set bits are merged into consecutive address intervals, adjacent change registers are merged into a single range report, further reducing the number of messages. After reporting, the change register bitmap is cleared, and the change is recalculated in the next cycle. When Hai Quantum devices report at high frequencies, the WAN bandwidth usage is reduced to a level comparable to the actual data jumps.

[0117] Furthermore, it also includes: an OTA upgrade area with a base address of 32768 is separately allocated in the partition memory mapping, the OTA upgrade area is physically isolated from the read-only telemetry area and the read-write control area; the OTA upgrade area carries block handshake upgrade with block index and firmware CRC32, and when a block is lost, only the data block corresponding to the block index is retransmitted, and the service of other partitions is not affected during the upgrade.

[0118] The gateway further divides the OTA upgrade area within the partitioned memory mapping, with register address 32768 as its base address. The register address range occupied by the OTA upgrade area starts at 32768 and does not overlap with the address range of the read-only telemetry area (8192 to 20479) and the address range of the read-write control area (20480 to 32767). Data written to the OTA upgrade area always has a target register address no less than 32768, falling outside the address range of the read-only telemetry area and the read-write control area, thus achieving physical isolation between the OTA upgrade area and the read-only telemetry area and the read-write control area. The OTA upgrade area uses a block index and firmware CRC32 to carry out block-based handshake firmware delivery: Before firmware delivery, the gateway first writes the target firmware version number to the version register of the OTA upgrade area. The high byte of the target firmware version number carries the minimum hardware major version number required by the target firmware, and the low byte carries the version number of the target firmware. The node reads the hardware version field and the current firmware version field in the general network identity area, and extracts its high byte and low byte from the target firmware version number written by the gateway. If the major version number of the hardware version field is lower than the minimum hardware major version number required by the target firmware, it is determined that the hardware version is incompatible. If the hardware version is incompatible or the version number of the target firmware is lower than the minimum hardware major version number required by the target firmware, it is considered that the hardware version is incompatible. When a node refuses to send firmware when the version number is loaded, the gateway terminates the OTA upgrade process and reports the OTA upgrade rejection and its reason to the cloud through the 4G communication module. The firmware is divided into fixed-length data blocks. The length of the OTA firmware block depends on the maximum number of registers that a single frame of the ModBus write multi-register instruction can carry. It is independent of the block length of the service data block described in step S12 and is not required to be consistent with the block length of the service data block. Each data block is assigned a block index. The gateway sends the firmware block by block using the ModBus write multi-register instruction and encodes the block index of the data block as the starting register address of the write multi-register instruction. After receiving the data, the node stores it in the download area according to the block index.The block loss determination condition is as follows: If the gateway sends a data block for a certain block index and does not receive a response corresponding to that block index within the timeout period, the data block is determined to be lost. Only the data block corresponding to the block index is resent, and the entire firmware is not resent from the beginning. Each block is sent strictly serially according to the block index number. The next block is sent only after the previous block receives a valid response. The node responds to each block by writing back the starting register address using the standard response frame of the ModBus write multi-register instruction. The gateway verifies the validity of the response by using the function code of the response frame equal to the write multi-register function code and the written starting register address equal to the starting register address corresponding to the sent block index. The number of retransmissions for a single block does not exceed the maximum number of retries given in the configuration. The maximum number of retries is a positive integer given in the configuration. Its value is determined by taking the smallest positive integer that makes the probability of continuous packet loss lower than the acceptable OTA failure probability limit based on the single transmission and reception packet loss rate of the Mesh link. For example, it is three to five times. If no valid response is received after exceeding the maximum number of retries, the current OTA upgrade process is terminated and the target node is marked as OTA failure. After all data blocks have been distributed, the node calculates the CRC32 of the entire download area and compares it with the CRC32 of the firmware distributed by the gateway. If they are equal, the gateway writes the agreed flashing instruction to the flashing trigger register of the OTA upgrade area. After receiving the flashing instruction, the node sets the flashing mark, moves the firmware in the download area to the running area, and restarts to complete the flashing. If they are not equal, the boot area is not overwritten.

[0119] Mesh links are prone to packet loss and have a limited number of bytes per frame. By dividing the firmware into fixed-length data blocks with block indexes, any lost block can be retransmitted individually based on its block index without retransmitting the entire packet. The OTA upgrade area base address 32768 is located above the upper limit of the read / write control area address and does not overlap with the address ranges of the read-only telemetry area and the read / write control area. Data written to the OTA upgrade area does not fall into other partitions and does not interfere with telemetry and control services during the upgrade process.

[0120] The firmware is distributed in blocks according to the block index and the integrity of the whole chip is verified by firmware CRC32. When a block is lost in the weak Mesh network, only the data block of the corresponding block index needs to be retransmitted. The retransmission overhead is equivalent to the number of lost blocks rather than the total amount of firmware. The OTA upgrade area is physically isolated from the read-only telemetry area and the read-write control area by address range. The write operation of moving firmware blocks does not touch the telemetry and control registers. During the upgrade, the voltage monitoring, lighting control and other partition services of the photovoltaic floor tiles continue to operate as usual until the CRC32 verification of the whole chip firmware passes before the flashing command is issued.

[0121] Example 2

[0122] like Figure 1As shown, this embodiment provides an edge gateway for implementing the heterogeneous device data aggregation method based on ModBus homomorphic memory mapping described in Embodiment 1. The edge gateway includes a processor, a memory, a communication module, and a local human-machine interface touch screen. The components are interconnected via an internal bus, and the communication module integrates a serial communication bus interface.

[0123] The processor is a microcontroller scheduling core built into the gateway. As the execution body of the method, it is responsible for polling scheduling and online judgment, pointer crossing and four-item verification of return frames, structural alignment verification on the reserved verification area, memory copy restoration of IEEE-754 floating-point telemetry data, and operations such as arithmetic addressing verification of control instructions and polling interval distribution. The memory includes two parts: storage medium and runtime memory. The storage medium stores computer programs that can run on the processor. The runtime memory establishes a globally unique device shadow pool. The device shadow pool is divided according to the unified memory mapping described in Embodiment 1, using the general network identity area base address 1000, the read-only telemetry area base address 8192, and the read-write control area base address 20480. Each device species is allocated a fixed-length data block with a reserved verification area at the end for real-time mapping of the register states of heterogeneous sub-devices such as photovoltaic tiles, streetlights, and downlights. The runtime memory also maintains a control instruction queue and a change register bitmap covering the read-only telemetry area.

[0124] The communication module includes a 4G communication module, a wireless mesh module, and a serial communication bus interface. The 4G communication module receives control commands from the cloud and reports telemetry data and incremental reporting messages to the cloud. The wireless mesh module and the serial communication bus interface are used to send and receive ModBus frames with each heterogeneous sub-device node. The local human-machine interface touchscreen receives user operations such as switching on / off, dimming, and color adjustment, and directly generates control commands based on the one-to-one binding relationship between control data flow identifiers and ModBus register physical addresses.

[0125] When the processor executes the computer program, it implements the heterogeneous device data aggregation method based on ModBus homomorphic memory mapping as described in Embodiment 1. That is, it sequentially implements steps such as obtaining unified memory mapping in step S10, polling and restoring telemetry data in step S20, issuing control commands during the polling interval in step S30, and further implementation steps such as offline to online full harvesting, reading budget decreasing with backlog depth, incremental reporting, and OTA block upgrade, which will not be elaborated here.

[0126] The foregoing description is illustrative of the invention and should not be construed as limiting it. Although several exemplary embodiments of the invention have been described, those skilled in the art will readily understand that many modifications can be made to the exemplary embodiments without departing from the novel teachings and advantages of the invention. Therefore, all such modifications are intended to be included within the scope of the invention as defined in the claims. It should be understood that the foregoing description is illustrative of the invention and should not be construed as limiting it to the specific embodiments disclosed, and modifications to the disclosed embodiments and other embodiments are intended to be included within the scope of the appended claims. The invention is defined by the claims and their equivalents.

Claims

1. A heterogeneous device data aggregation method based on ModBus homomorphic memory mapping, characterized in that, include: A device shadow pool is established at the edge gateway. The ModBus register address space is divided into a general network identity area, a read-only telemetry area, and a read-write control area. For each device species, a fixed-length data block with a reserved check area at the end is allocated in the read-only telemetry area and the read-write control area in single-byte alignment. The length of the fixed-length data block is the block length, resulting in a unified memory mapping. Based on the unified memory mapping, the target node is polled, the device species number is obtained by reading the general network identity area of ​​the target node, the ModBus payload is extracted from the return frame of the target node and verified, the ModBus payload that passes the verification is structurally aligned and then copied into the memory and written into the data block corresponding to the device species number in the device shadow pool, and the telemetry data is restored. The control commands issued by the human-machine interface or the cloud, along with the target register address, are written into the control command queue. The control command queue is checked during the polling intervals. If there are control commands to be processed, the control area base address is calculated based on the device species number and block length. After verifying the target register address, the write command is sent to the target node. After processing is completed, polling is resumed.

2. The heterogeneous device data aggregation method based on ModBus homomorphic memory mapping according to claim 1, characterized in that, The steps for outputting a unified memory map are as follows: A device shadow pool is established in the edge gateway memory, and a general network identity zone, a read-only telemetry zone, and a read-write control zone are divided. Each zone is anchored with a fixed base address to obtain a partitioned memory mapping.

3. The heterogeneous device data aggregation method based on ModBus homomorphic memory mapping according to claim 2, characterized in that, The output steps of unified memory mapping also include: In partitioned memory mapping, a fixed-length data block is allocated for each device species in the read-only telemetry area and the read-write control area. The front of the fixed-length data block is the valid data field and the tail is the reserved verification area. When the device function is iterated, only the field is added in the reserved verification area without changing the starting address and arrangement order of the existing fields. Ensure that the shadow structure on the gateway side and the structure on the node side are arranged in single-byte alignment and have the same binary byte order, and output a unified memory mapping.

4. The heterogeneous device data aggregation method based on ModBus homomorphic memory mapping according to claim 2, characterized in that, The fixed base address is anchored as follows: the base address of the general network identity area is 1000, the base address of the read-only telemetry area is 8192, and the base address of the read-write control area is 20480. The read-only telemetry area and the read-write control area are physically isolated, and the control commands written to the read-write control area do not fall into the read-only telemetry area.

5. The heterogeneous device data aggregation method based on ModBus homomorphic memory mapping according to claim 1, characterized in that, The analysis steps for verifying ModBus loads include: Read the online status of the target node in the device shadow pool: If it is unknown or offline, enter the identity detection mode, and only issue the command to read the general network identity area to obtain the device species number and update the online status; if it is online, enter the telemetry reading mode, select the address range to be read in this round according to the device species number and the polling cycle count of each sensor, and issue the command to read the address range to be read in this round.

6. The heterogeneous device data aggregation method based on ModBus homomorphic memory mapping according to claim 5, characterized in that, The analysis steps for the verified ModBus load also include: Based on the header, length field, and trailer of the return frame from the target node, the pure ModBus payload and source node address are extracted by using the length field as a pointer to cross the location. The payload is then checked sequentially by the source node address, length, CRC, and function code. The length check involves comparing the number of extracted ModBus payload bytes with the expected number of payload bytes calculated based on the number of registers contained in the address range to be read in this round, to obtain the ModBus payload that passes the check.

7. The heterogeneous device data aggregation method based on ModBus homomorphic memory mapping according to claim 6, characterized in that, The steps to restore telemetry data include: Perform structural alignment verification on the ModBus loads that have passed the verification, and obtain the structural alignment verification value; When the structural alignment check value indicates that the structures at both ends are homomorphic, the ModBus payload is copied into the data block corresponding to the device shadow pool and the device species number, and into the target byte range corresponding to the address range to be read in this round, after memory copying. This restores the telemetry data in IEEE-754 floating-point format and updates the online status. When the structural alignment check value indicates structural mismatch, the ModBus payload is discarded, the online status of the target node is set to zero and marked as structural mismatch, triggering a re-read handshake for the firmware version of the target node.

8. The heterogeneous device data aggregation method based on ModBus homomorphic memory mapping according to claim 7, characterized in that, The steps for performing structural alignment verification on the verified ModBus loads include: The field offset sequence is formed by arranging the field boundaries of a fixed-length data block according to the prefix sum. The reserved check area is determined by the last segment of the field offset sequence. The reserved check area is filled by nodes with reserved reference constants. The structural alignment check value is obtained by summing the ModBus loads that pass the check byte by byte within the reserved check area.

9. The heterogeneous device data aggregation method based on ModBus homomorphic memory mapping according to claim 7, characterized in that, The determination steps for determining the structural alignment check value to characterize the homomorphism of the two ends of the structure include: comparing the structural alignment check value with the expected value corresponding to the reserved reference constant; if they are consistent, the two ends of the structure are determined to be homomorphic; if they are inconsistent, the structure is determined to be mismatched.

10. The heterogeneous device data aggregation method based on ModBus homomorphic memory mapping according to claim 1, characterized in that, The steps for calculating the base address of the control area include: When receiving operations from human-machine interface controls or cloud-based commands, because the data flow identifiers of the human-machine interface controls are bound one-to-one with the physical addresses of ModBus registers, control instructions containing target node identifiers, target register addresses, and control values ​​are directly generated without going through an address translation table. Write control instructions into the control instruction queue in a non-blocking manner; establish an arithmetic addressing relationship so that the control area base address is equal to the sum of 20480, the device species number minus one, and the block length. Calculate the control area base address of the target node based on this, and verify that the target register address falls into a valid control block with the control area base address as the starting point and a length equal to the block length.

11. The heterogeneous device data aggregation method based on ModBus homomorphic memory mapping according to claim 10, characterized in that, The steps to resume polling include: checking the control instruction queue during the polling interval; suspending and saving the current polling position when it is not empty; issuing write instructions to the control area register of the target node first; and restoring the saved current polling position after receiving an acknowledgment or timeout.

12. The heterogeneous device data aggregation method based on ModBus homomorphic memory mapping according to claim 7, characterized in that, It also includes: when a target node goes from offline to online, the polling cycle count of each of its sensors is set to full so that a full harvest can be forced in the next cycle; and the number of data blocks contained in the address range to be read in this round decreases as the backlog depth of the control instruction queue in the previous cycle increases.

13. The heterogeneous device data aggregation method based on ModBus homomorphic memory mapping according to claim 1, characterized in that, Also includes: Maintain the change register bitmap covering the read-only telemetry area. When the value copied to memory is different from the original value in the device shadow pool, set the corresponding bit in the change register bitmap. Periodically scan the change register bitmap, merge consecutively set bits into consecutive address ranges, generate incremental reporting messages only for consecutive address ranges, and clear the change register bitmap after reporting.

14. The heterogeneous device data aggregation method based on ModBus homomorphic memory mapping according to claim 4, characterized in that, Also includes: In the partitioned memory mapping, an OTA upgrade area with a base address of 32768 is separately allocated. The OTA upgrade area is physically isolated from the read-only telemetry area and the read-write control area. The OTA upgrade zone uses block indexes and firmware CRC32 to carry out block handshake upgrades. When a block is lost, only the data block corresponding to the block index is retransmitted. The upgrade does not affect the services of other partitions.

15. An edge gateway, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes a computer program, it implements the heterogeneous device data aggregation method based on ModBus homomorphic memory mapping as described in any one of claims 1-14.

Images