A data processing method, system and apparatus
By caching timestamped runtime data when IoT devices are offline and constructing historical data packets for retransmission after the network is restored, the problem of data loss caused by network interruption is solved, data integrity and traceability are achieved, and the logic of resuming interrupted transmission is simplified.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- HANGZHOU KANGBEI MOTOR
- Filing Date
- 2025-12-24
- Publication Date
- 2026-04-17
AI Technical Summary
The operational data generated by IoT devices during network outages cannot be transmitted in real time, resulting in the loss of historical data, making it impossible to trace and affecting the continuity and integrity of data. This poses a security risk, especially in applications such as cold chain transportation monitoring and production safety early warning.
When the terminal device is offline, it caches the runtime data with timestamps and constructs historical data packets after the network is restored. These packets are then resent using a specific start register address flag, enabling the platform to distinguish between real-time data and historical data and accurately recover historical data using the timestamps carried in the packets.
Without changing the original message structure or adding extra signaling fields, the problem of data loss caused by network interruption was solved, data integrity was guaranteed, and the implementation logic of the breakpoint resume function was simplified.
Smart Images

Figure CN121396773B_ABST
Abstract
Description
Technical Field
[0001] This disclosure relates to the field of computer communication technology, and in particular to a data processing method, system and apparatus. Background Technology
[0002] With the rapid development of IoT technology, a large number of IoT terminal devices, such as environmental monitoring sensors, smart home appliances, and industrial automation equipment, are widely deployed in various scenarios. These devices typically need to periodically report the operational data or environmental parameters they collect to a remote cloud-based IoT platform via wireless communication networks (such as 4G, 5G, NB-IoT, etc.) for centralized monitoring, data analysis, and fault diagnosis.
[0003] In typical IoT data reporting applications, the terminal device and the platform use a client-server communication model. Since terminal devices are usually resource-constrained (e.g., weak computing power, small memory), the communication protocol between them is often designed to be relatively simple, such as using a register-based message format similar to the Modbus protocol. This protocol has a clear structure, low overhead, and is easy to implement in embedded systems.
[0004] However, the stability of the wireless communication link is a key factor affecting the reliability of data reporting. Due to signal interference, network congestion, or equipment movement, the network connection between the terminal device and the platform may be temporarily interrupted, i.e., "dropped." During the period when the terminal device is offline, its internal operational data acquisition function usually continues to operate normally, but the generated operational data cannot be sent to the platform in real time. Existing simple communication protocols generally do not have mechanisms to handle long-term network interruptions. When the network connection is restored and the terminal device comes back online, a large amount of operational data generated during the offline period will be lost, resulting in gaps in the platform's historical data records. This is a fatal flaw for applications that require ensuring data continuity and integrity (such as cold chain transportation monitoring, production safety early warning, etc.), making it impossible for managers to effectively trace and analyze the operational status of the terminal device during the offline period, thus creating potential security risks. Summary of the Invention
[0005] This disclosure provides a data processing method, system, and apparatus, which aims to solve the technical problem of loss and untraceability of historical data of Internet of Things (IoT) devices due to network interruption.
[0006] The technical solution disclosed herein is implemented as follows:
[0007] In a first aspect, this disclosure provides a data processing method applied to a terminal device. The data processing method includes: storing the current running data and current timestamp generated by the terminal device as a historical data record when the network connection between the terminal device and the platform is offline; generating a historical data message based on at least one historical data record when the network connection is restored to online status; the historical data message includes a first starting register address, a register count field, and a data area; the first starting register address is used to indicate a preset address for the historical data message including the timestamp; the data area includes at least one historical data record; the value of the register count field represents the total number of registers occupied by all historical data records contained in the data area; and sending the historical data message to the platform.
[0008] Secondly, this disclosure provides a data processing method applied to a platform. The data processing method includes: receiving a data packet sent by a terminal device, the data packet including a starting register address, a register count field, and a data area; when the starting register address is a first starting register address, determining the number of historical data records included in the data packet based on the value of the register count field and the register length of a preset single historical data record, the first starting register address being used to indicate that the data packet is a historical data packet including a preset address; cyclically parsing the timestamps and running data of the specified number of historical data records from the data area, and storing the running data based on the timestamps.
[0009] Thirdly, this disclosure provides a data processing apparatus applied to a terminal device. The data processing apparatus includes: a storage section for storing the current running data and current timestamp generated by the terminal device as a historical data record when the network connection between the terminal device and the platform is offline; a processing section for generating a historical data message based on at least one historical data record when the network connection is restored to online status. The historical data message includes a first starting register address, a register count field, and a data area. The first starting register address is used to indicate a preset address for the historical data message including a timestamp. The data area includes at least one historical data record, and the value of the register count field represents the total number of registers occupied by all historical data records contained in the data area; and a sending section for sending the historical data message to the platform.
[0010] Fourthly, this disclosure provides a data processing apparatus applied to a platform. The data processing apparatus includes: a receiving section for receiving data packets sent by a terminal device, the data packets including a starting register address, a register count field, and a data area; a determining section for determining the number of historical data records included in the data packet based on the value of the register count field and a preset register length for a single historical data record, provided that the starting register address is a first starting register address; the first starting register address for indicating that the data packet is a historical data packet including a preset address; a parsing section for cyclically parsing the timestamps and running data of the specified number of historical data records from the data area; and a storage section for storing the running data based on the timestamps.
[0011] Fifthly, this disclosure provides an electronic device including a processor, a memory, and a program or instructions stored in the memory and executable on the processor, wherein the program or instructions, when executed by the processor, implement the steps of the data processing method as described in the first and / or second aspects.
[0012] In a sixth aspect, this disclosure provides a computer-readable storage medium on which a program or instructions are stored, which, when executed by a processor, implement the steps of the data processing method as described in the first and / or second aspects.
[0013] In a seventh aspect, this disclosure provides a computer program product, wherein the computer program product includes a computer program or instructions, which, when executed on a processor, cause the processor to execute the computer program or instructions to implement the steps of the data processing method as described in the first and / or second aspects.
[0014] Eighthly, this disclosure provides a chip including a processor and a communication interface coupled to the processor, the processor being used to run programs or instructions to implement the steps of the data processing methods as described in the first and / or second aspects.
[0015] Ninthly, this disclosure provides a data processing system, which includes: at least one terminal device, a platform, and a communication network, wherein the at least one terminal device and the platform communicate through the communication network;
[0016] A terminal device is configured to, when the network connection between the terminal device and the platform is offline, store the current running data and current timestamp generated by the terminal device as a historical data record; and, when the network connection is restored to online, generate a historical data packet based on at least one historical data record, the historical data packet including a first starting register address, a register count field, and a data area, wherein the first starting register address is used to indicate a preset address including the timestamp of the historical data packet, the data area includes at least one historical data record, and the value of the register count field represents the total number of registers occupied by all historical data records contained in the data area; and send the historical data packet to the platform.
[0017] The platform is configured to receive data packets sent by terminal devices. The data packets include a starting register address, a register count field, and a data area. When the starting register address is a first starting register address, the platform determines the number of historical data records included in the data packet based on the value of the register count field and the preset register length of a single historical data record. The first starting register address is used to indicate that the data packet is a historical data packet with a preset address including a timestamp. The platform also cyclically parses the timestamps and running data of the specified number of historical data records from the data area and stores the running data based on the timestamps.
[0018] This disclosure provides a data processing method, system, and apparatus. By caching timestamped runtime data when a terminal device is offline, and then retransmitting a historical data packet marked with a specific starting register address after the device reconnects, the platform can easily distinguish between real-time and historical data by simply determining this address value, and accurately recover the historical data using the timestamp carried in the packet. This solution solves the problem of data loss and untraceability caused by network interruptions without changing the original packet structure or adding additional signaling fields, ensuring data integrity, and greatly simplifying the implementation logic of the breakpoint resume function. Attached Figure Description
[0019] Figure 1 This is a schematic diagram of the structure of a data processing system provided in this disclosure.
[0020] Figure 2 This is a schematic diagram illustrating the data interaction process between a terminal device and a platform, as provided in this disclosure.
[0021] Figure 3 This is a schematic diagram of a queue structure for caching historical data records provided in this disclosure.
[0022] Figure 4 This is a schematic diagram illustrating the composition of a historical data message provided in this disclosure.
[0023] Figure 5 This is a flowchart illustrating an optimized batch reporting method provided in this disclosure.
[0024] Figure 6 This is a schematic diagram illustrating another process for data interaction between a terminal device and a platform, as provided in this disclosure.
[0025] Figure 7 This is a schematic diagram illustrating the composition of a real-time data message provided in this disclosure.
[0026] Figure 8 This is a schematic diagram illustrating another process of data interaction between a terminal device and a platform provided in this disclosure.
[0027] Figure 9 This is a schematic diagram illustrating the composition of a hybrid data message provided in this disclosure.
[0028] Figure 10 This is a structural block diagram of a data processing device provided in this disclosure.
[0029] Figure 11 This is a structural block diagram of another data processing apparatus provided in this disclosure.
[0030] Figure 12 This is a schematic diagram of the hardware structure of an electronic device provided in this disclosure. Detailed Implementation
[0031] The technical solutions in the embodiments of this disclosure will be clearly described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of this disclosure. All other embodiments obtained by those skilled in the art based on the embodiments of this disclosure are within the scope of protection of this disclosure.
[0032] Please see Figure 1 , Figure 1 This is a schematic diagram of the architecture of a data processing system 10 provided in an embodiment of this application. The data processing system 10 aims to provide a reliable IoT data acquisition and monitoring solution, particularly suitable for scenarios with unstable network environments.
[0033] The data processing system 10 may include at least one terminal device 110, a communication network 120, and a platform 130.
[0034] In this embodiment, terminal device 110 can be a temperature control device, such as a smart temperature controller for cold chain logistics vehicles, fresh food supermarket freezers, or pharmaceutical warehouses. Of course, terminal device 110 is not limited to temperature control devices; it can be any IoT device that needs to periodically report data, such as a smart meter or environmental monitoring station. The core function of terminal device 110 is to collect one or more of its own operating parameters and send these parameters to platform 130 via communication network 120.
[0035] Specifically, the terminal device 110 typically integrates hardware such as sensors, a processor, memory, a communication module, and a real-time clock. The processor, usually a microcontroller or embedded microprocessor, is responsible for executing the program stored in the memory and controlling various functions of the device, including data acquisition, logical judgment, and the construction and parsing of communication protocols. The memory includes program memory, data memory, and a dedicated non-volatile storage area (such as a separate data flash chip) for caching historical data. The characteristic of the non-volatile storage area is that data is not lost after power failure, which is key to achieving offline caching. Sensors are used to collect the physical quantities that the terminal device 110 needs to monitor, i.e., operational data, such as temperature sensors, humidity sensors, and pressure sensors. When the terminal device 110 is a temperature control device, it includes at least one temperature sensor for measuring ambient temperature. The communication module is responsible for communication between the terminal device 110 and the outside world. In this embodiment, it is a 4G or 5G wireless communication module, which enables the terminal device 110 to establish a connection with the remote platform 130 through the communication network 120 (e.g., a 4G mobile network of an operator). The real-time clock is a separate timing circuit that maintains time accuracy even when the main MCU is in sleep mode, providing precise timestamps for the acquired operational data.
[0036] The communication network 120 can be any wide area network or local area network that supports data exchange between the terminal device 110 and the platform 130, such as a cellular mobile network (e.g., 4G, 5G), a low-power wide-area network (LPWAN, such as LoRa, NB-IoT), or the Internet. The communication network 120 provides physical and logical channels for data transmission.
[0037] Platform 130 typically refers to a backend service system deployed on a cloud server or private data center, also known as an Internet of Things (IoT) platform. Platform 130 is responsible for communicating with a large number of terminal devices 110, enabling functions such as access management, data reception and parsing, data storage, and data processing and analysis for the terminal devices 110. Within the framework of the data processing system 10 disclosed herein, the terminal devices 110 and platform 130 work collaboratively to ensure that even when the communication network 120 is unstable, data can still be uploaded to platform 130 completely, accurately, and efficiently.
[0038] Specifically, see Figure 2 , Figure 2 This is a schematic diagram illustrating the data interaction between a terminal device 110 and a platform 130 via a communication network 120, as provided in this embodiment of the disclosure. The terminal device 110 executes steps S201 to S203, and the platform 130 executes steps S204 to S207.
[0039] In step S201, when the network connection between the terminal device and the platform is offline, the current running data and current timestamp generated by the terminal device are stored as a historical data record.
[0040] Terminal device 110 collects a set of current operating data at preset time intervals (e.g., every 30 seconds), such as fan speed of 400 RPM and freezer temperature of 5.0℃. Simultaneously, it reads the current time from a real-time clock. To facilitate cross-system processing, this time is typically converted to a Unix timestamp format. For example, 1747045852 is a 4-byte integer corresponding to the time 18:30:52 on May 12, 2025.
[0041] When the network connection between terminal device 110 and platform 130 is offline, the current operating data (fan speed 400, freezer temperature 5.0°C) and the corresponding current time (1747045852) are packaged into a structured data unit and recorded as historical data record.
[0042] See Figure 3 , Figure 3 A schematic diagram of an exemplary queue structure for caching historical data records is shown. A specific area in local memory (such as Flash) is allocated as a data buffer 300. This data buffer 300 can be organized into a First-In, First-Out (FIFO) queue. Each historical data record includes a timestamp and runtime data. Figure 3The historical data records shown, from timestamp 1 to timestamp N, are arranged from oldest to newest. The historical data record consisting of timestamp N and running data N is the most recently generated and is added to the end of the queue. Each historical data record in the queue contains a complete timestamp and corresponding running data. Furthermore, to prevent data buffer overflow, various strategies can be designed. For example: circular queue: when the queue is full, new data overwrites the oldest data. Discard strategy: when the queue is full, new data is directly discarded. Priority strategy: if data has different importance levels, data with lower importance can be discarded first. The specific overflow prevention strategy used is not limited in this disclosure.
[0043] After the caching operation is completed, the process returns to step S201 to continue the next round of data collection and network status assessment.
[0044] In step S202, when the network connection status is restored to online status, a historical data packet is generated based on at least one historical data record.
[0045] The historical data message includes a first starting register address, a register count field, and a data area. The first starting register address is used to indicate a preset address for the historical data message, including a timestamp. The data area includes at least one historical data record. The value of the register count field represents the total number of registers occupied by all historical data records contained in the data area.
[0046] Terminal device 110 determines its network connection status through a response-based acknowledgment mechanism. Each time terminal device 110 sends a data packet to platform 130, it starts a timer. If it does not receive a response packet from platform 130 before the timeout (e.g., within 5 seconds), terminal device 110 determines it is in an "offline state"; otherwise, it is in an "online state".
[0047] Since terminal device 110 is typically resource-constrained, the communication protocol between terminal device 110 and platform 130 is designed to be relatively simple, such as using the Modbus-like protocol provided in this disclosure. This disclosure aims to ensure that the traceability of operational data after a disconnection is achieved without changing the protocol format. Historical data packets refer to data units transmitted between terminal device 110 and platform 130, conforming to the communication protocol between the two, and having a fixed format and structure.
[0048] Table 1 shows the data structures corresponding to the Modbus protocol.
[0049] Table 1. Data Structures Corresponding to Modbus Protocols
[0050]
[0051] Among them, the start byte is a preset field indicating the start of the message, occupying one byte, such as 0xAA; the device address is used to indicate the address of terminal device 110, occupying two bytes; the command is used to indicate the function of the message, occupying one byte, such as 0x50 command code indicating that terminal device 110 uploads data to platform 130; the CRC check code is used to verify whether the message is complete, occupying two bytes; the register count, occupying one byte, indicates the total number of registers; and the running data is the actual data collected.
[0052] In Modbus-like protocols, the start register address is an address number used to specify a specific location in the internal storage area of terminal device 110. Each piece of operational data (such as temperature and speed) to be read or written within terminal device 110 is mapped to a unique register address. In this disclosure, this field is given a dual meaning: firstly, a traditional address pointing function, and secondly, an implicit identifier for the data type. When the start register address is the first start register address, it identifies the data type as a historical data record.
[0053] See Figure 4 , Figure 4 A schematic diagram illustrating the composition of an exemplary historical data packet is shown. The example uses a start byte of 0xAA, a command of 0x50, a CRC checksum of 0x566B, and a device address of 0x01.
[0054] The first starting register address field 401 is set to a special, preset address that corresponds to the "timestamp" parameter, such as... Figure 4 The address shown is 0x0001. This 0x0001 value is used to tell Platform 130 that the data packet is historical data with a timestamp.
[0055] The register count field is 402. Because historical data packets now include a 4-byte timestamp in addition to the original runtime data (in Modbus-like protocols, a 16-bit register occupies 2 bytes, so a 4-byte timestamp requires 2 registers), the number of registers needs to be increased accordingly. For example, if 2 bytes of runtime data originally occupied 2 registers, now with the timestamp, it requires 2 more registers, for a total of 4 registers. Figure 4 The value of this field shown is 0x04.
[0056] The value of register count field 402 can be determined based on the number of at least one historical data record and the preset register length of a single historical data record. For example, if a historical data record requires two registers and the number of at least one historical data record is 4, then the value of register count field 402 is 8.
[0057] Data area 403, each byte represents the value of a register. For example... Figure 4 As shown, 0x6821 represents the value of register 1, 0xCDDC represents the value of register 2, 0x0190 represents the value of register 3, and 0x01F4 represents the value of register 4. Registers 1 and 2 store a timestamp, i.e., 0x6821CDDC, corresponding to the time 2025-05-12 18:30:52. Registers 3 and 4 contain the runtime data corresponding to this timestamp. Figure 4 The fan speed shown is 0x0190, which is 400, and the freezer temperature is 0x01F4, which is 500. Multiplying these values by the preset coefficient 500×0.01=5.
[0058] In step S203, historical data packets are sent to the platform.
[0059] After the historical data message is constructed, the terminal device 110 sends the historical data message to the platform 130 and clears the corresponding historical data record in the data buffer.
[0060] In step S204, a data packet sent by the terminal device is received.
[0061] The data message includes the starting register address, register count field, and data area.
[0062] In step S205, when the starting register address is the first starting register address, the number of historical data records included in the data message is determined according to the value of the register count field and the preset register length of a single historical data record.
[0063] The first start register address is used to indicate that the data packet is a historical data packet with a preset address including a timestamp.
[0064] In step S206, the timestamps and running data of the specified number of historical data records are cyclically parsed from the data area.
[0065] In step S207, runtime data is stored based on timestamps.
[0066] The backend service of platform 130 listens on a designated port, receives data packets from terminal device 110, and performs basic integrity checks (such as CRC checks). Platform 130 parses the data packets according to a predefined protocol format and extracts the starting register address, register count, and data area.
[0067] If the platform 130 determines that the value of the "starting register address" field in the data packet is equal to the preset first starting register address (such as 0x0001), it determines that the data packet is a historical data packet, parses the batch data in a loop according to the number of registers, and stores it into the database based on their respective timestamps.
[0068] Specifically, platform 130 reads the value of the "register count" field (e.g., 40) and combines it with a preset "register length of a single historical data record" (e.g., 4). The quotient of the value of the register count field and the register length of a single historical data record is used to determine the number of historical data records included in the historical data message.
[0069] Platform 130 processes the data area in a loop, executing N times (N equals the number of historical data records). In each loop, it reads the length of a single historical data record, extracting the timestamp and corresponding runtime data. The N parsed historical data records are then batch-inserted into the database, with each record's "Data Time" field using its own embedded timestamp. For example, for timestamp 1747045852, the corresponding record's time in the database will be stored as "2025-05-12 18:30:52".
[0070] In this embodiment, a historical data packet marked with a specific starting register address is constructed for retransmission. This allows the platform 130 to distinguish between real-time and historical data simply by judging the address value, and to accurately recover the historical data using the timestamp carried in the packet. This solution solves the problem of data loss and untraceability caused by network interruption without changing the original packet structure or adding additional signaling fields, ensuring data integrity, and greatly simplifying the implementation logic of the breakpoint resume function.
[0071] In some embodiments, to improve the efficiency of re-reporting after network recovery, the terminal device 110 may not need to send historical data records one by one. For example... Figure 5 The diagram shows a flowchart of an optimized batch reporting method. Terminal device 110 executes steps S501 to S503, and platform 130 executes steps S504 to S507.
[0072] In step S501, when the network connection between the terminal device and the platform is offline, the current running data and current timestamp generated by the terminal device are stored as a historical data record.
[0073] In step S502, when the network connection status is restored to online status, a historical data packet is generated based on multiple historical data records.
[0074] Terminal device 110 can retrieve multiple (e.g., 10) historical data records from the buffer queue at once to construct a longer historical data message. The starting register address of this historical data message remains the first starting register address, but the value of the "register count" field will become much larger. For example, if a single historical record consists of one 4-byte timestamp and two 2-byte runtime data records, and 10 historical data records are reported simultaneously, the corresponding register count field value will be 40. The data area will then contain multiple sets of repeating "timestamp and runtime data" structures.
[0075] When parsing data, Platform 130, after identifying a historical data packet, it iteratively parses all batch-reported data records based on the total data length and the fixed length of each historical data record, and stores them in the database all at once. This method reduces packet header overhead and the number of network interactions, and can clear the local cache more quickly when network conditions are good.
[0076] In step S503, historical data packets are sent to the platform.
[0077] In step S504, a data packet sent by the terminal device is received.
[0078] In step S505, when the starting register address is the first starting register address, the number of historical data records included in the data message is determined according to the value of the register count field and the preset register length of a single historical data record.
[0079] In step S506, the timestamps and running data of the specified number of historical data records are cyclically parsed from the data area.
[0080] In step S507, runtime data is stored based on timestamps.
[0081] For details of steps S501, S503 to S507, please refer to the description of steps S201, S203 to S207 above, which will not be repeated here.
[0082] In some embodiments, this refers to data interaction in an online state. For example... Figure 6 The diagram illustrates the interaction process between a platform 130 and a terminal device 110. The terminal device 110 executes steps S601 to S605, and the platform 130 executes steps S606 to S610.
[0083] In step S601, when the network connection status is online, a real-time data packet is generated.
[0084] The real-time data message includes the second starting register address and the real-time collected running data. The second starting register address is different from the first starting register address.
[0085] When the network connection is online, the goal of the terminal device 110 is to send out the latest collected data as soon as possible. It will construct a "real-time data message", which is "produced and sent immediately" and is sent out as soon as it is generated.
[0086] See Figure 7 , Figure 7 An exemplary composition of a real-time data packet is shown, which follows the same Modbus format as the aforementioned historical data packets. The example used is a start byte of 0xAA, a command of 0x50, a CRC checksum of 0x263C, and a device address of 0x01.
[0087] The second start register address field, 701, is a key field for distinguishing message types. For real-time data messages, this address is set to the address of the first actual operating parameter. According to the communication point table, the address for fan speed is 0x0003, and for freezer temperature is 0x0004. Therefore, if these two parameters are to be sent, the start address is set to 0x0003.
[0088] The communication point table is a pre-stored guide table that includes the parameter type corresponding to the register start address, such as 0x0001 for timestamp, 0x0003 for fan speed, 0x0004 for freezer temperature, as well as the scaling factor, length, and unit of each parameter.
[0089] Register count field 702: Taking the reported fan speed and freezer temperature as an example, there are two corresponding registers, so the value of this field is 0x02.
[0090] Data area 703: Stores the values of various operating parameters sequentially, excluding timestamps. For example, fan speed 400 (0x0190 in hexadecimal), freezer temperature 500 (because the scaling factor is 0.01, the actual value 5.0 is represented as 500 in the protocol, which is 0x01F4 in hexadecimal).
[0091] In step S602, the real-time data message is sent to the platform.
[0092] After the construction is completed, the terminal device 110 sends the real-time data message to the platform 130.
[0093] In step S603, when the network connection between the terminal device and the platform is offline, the current running data and current timestamp generated by the terminal device are stored as a historical data record.
[0094] In step S604, when the network connection status is restored to online status, a historical data packet is generated based on at least one historical data record.
[0095] In step S605, historical data packets are sent to the platform.
[0096] In step S606, a data packet sent by the terminal device is received.
[0097] In step S607, when the starting register address is the first starting register address, the number of historical data records included in the data message is determined according to the value of the register count field and the preset register length of a single historical data record.
[0098] In step S608, the timestamps and running data of the specified number of historical data records are cyclically parsed from the data area.
[0099] In step S609, runtime data is stored based on timestamps.
[0100] In step S610, if the starting register address is the second starting register address, the running data in the data area is stored based on the platform's current time.
[0101] When the starting register address is not the first starting register address (e.g., 0x0001) (e.g., 0x0003), the platform 130 treats it as a real-time data message, directly parses the running data in the data area, and uses the current system time of the platform 130 as the data timestamp to store it in the database.
[0102] Through this simple, single-field-value-based judgment logic, Platform 130 can seamlessly process data from two sources, ultimately forming a complete, uninterrupted, and time-accurate data timeline at the database level.
[0103] It should be noted that steps S603 to S609 can be referred to in the description of steps S201 to S207 above, and will not be repeated here.
[0104] In this embodiment, a unified data message format is defined, cleverly reusing the "start register address" field in the message as an implicit data type identifier: when the terminal device 110 is offline, it caches timestamped runtime data, and when it re-uploads the historical data cached during the offline period after reconnecting, this address is set to a preset value pointing to the timestamp; while when transmitting real-time data, it is set to a regular data parameter address. The platform 130 can accurately distinguish and process the two types of data by judging the difference in this address value. This solution does not require adding or modifying protocol fields, achieves reliable traceability of historical data with low implementation complexity while maintaining the simplicity and compatibility of the protocol framework, and significantly reduces system development costs.
[0105] There is a situation where, when the network status returns to online, if there are many historical data records, it may not be possible to complete the transmission in a short time, but real-time data needs to be transmitted. In this case, to improve transmission efficiency, in some embodiments, such as... Figure 8 The diagram illustrates the interaction process between a platform 130 and a terminal device 110. The terminal device 110 executes steps S801 to S807, and the platform 130 executes steps S808 to S813.
[0106] In step S801, when the network connection status is online, a real-time data packet is generated.
[0107] In step S802, the real-time data message is sent to the platform.
[0108] In step S803, when the network connection between the terminal device and the platform is offline, the current running data and current timestamp generated by the terminal device are stored as a historical data record.
[0109] In step S804, when the network connection status is restored to online status, a historical data packet is generated based on at least one historical data record.
[0110] In step S805, historical data packets are sent to the platform.
[0111] In step S806, if at least one historical data record is not sent to the platform and real-time data is generated, a mixed data message is generated based on at least one historical data record and the real-time collected operation data.
[0112] The mixed data message includes a first starting register address, a register count field, and a data area. The data area includes at least one historical data record, a second starting register address, and real-time collected runtime data.
[0113] In step S807, the mixed data message is sent to the platform.
[0114] In step S808, a data packet sent by the terminal device is received.
[0115] In step S809, when the starting register address is the first starting register address, the number of historical data records included in the data message is determined according to the value of the register count field and the preset register length of a single historical data record.
[0116] In step S810, the timestamps and running data of the specified number of historical data records are cyclically parsed from the data area.
[0117] In step S811, runtime data is stored based on timestamps.
[0118] In step S812, after parsing the number of historical data records from the data area, if there is remaining data in the data area, the remaining data is stored based on the current time of the platform.
[0119] The mixed data message includes at least one historical data record that has not yet been uploaded to platform 130 and one currently generated real-time data record. Both types of data are reported to platform 130 in a single message. For example... Figure 9 As shown, the first starting register address field 901 is 0x0001, the register count field 902 is 0x04, and the data area 903 contains: 0x6821, 0xCDDC, 0x0190, 0x01F4, 0x0003, 0x02, 0x0180, 0x01F2. A historical data record requires a register length of 4, and the number of historical data records is 4 / 4, resulting in 1, indicating that there is one historical data record. Figure 9 Data area 904, a portion of data area 903, contains historical data records.
[0120] During parsing, after parsing a historical data record, Platform 130 determines that there is still 905 data records remaining in the data area. This remaining data 905 is identified as real-time data. Based on the data structure of register address, register count, and running data, the corresponding register address is determined to be 0x0003, the register count field to be 0x02, and the running data to be 0x0180 and 0x01F2. The current time of Platform 130 is used as the timestamp for data entry. This method allows for the transmission of both real-time and historical data in a single transmission, accommodating both data types and improving transmission efficiency.
[0121] In step S813, if the starting register address is the second starting register address, the running data in the data area is stored based on the platform's current time.
[0122] Figure 10 This is a structural block diagram of a data processing apparatus disclosed herein, applied to terminal device 110, such as... Figure 10 As shown, it includes:
[0123] The storage section 1001 is used to store the current running data and current timestamp generated by the terminal device as a historical data record when the network connection between the terminal device and the platform is offline.
[0124] The processing unit 1002 is used to generate a historical data packet based on at least one historical data record when the network connection status is restored to online status. The historical data packet includes a first starting register address, a register count field, and a data area. The first starting register address is used to indicate a preset address for the historical data packet including a timestamp. The data area includes at least one historical data record. The value of the register count field represents the total number of registers occupied by all historical data records contained in the data area.
[0125] The sending section 1003 is used to send historical data packets to the platform.
[0126] In some embodiments, the processing part 1002 is configured to generate historical data packets based on multiple historical data records when the network connection status is restored to online status.
[0127] In some embodiments, the processing unit 1002 is configured to generate a real-time data packet when the network connection status is online. The real-time data packet includes a second starting register address and real-time collected running data. The second starting register address is different from the first starting register address.
[0128] The sending section 1003 is used to send real-time data packets to the platform.
[0129] In some embodiments, the processing unit 1002 is configured to generate a mixed data message based on at least one historical data record and real-time collected runtime data when at least one historical data record is not sent to the platform and real-time data is generated. The mixed data message includes a first starting register address, a register count field, and a data area, the data area including: at least one historical data record and real-time collected runtime data.
[0130] Part 1003 sends the mixed data packet to the platform.
[0131] In this embodiment, each part can implement the implementation steps corresponding to the terminal device 110 in the above data processing system and achieve the same technical effect. To avoid repetition, it will not be described again here.
[0132] Figure 11 This is a structural block diagram of a data processing apparatus disclosed herein, applied to platform 130, such as... Figure 11 As shown, it includes:
[0133] The receiving section 1101 is used to receive data packets sent by the terminal device. The data packets include a start register address, a register count field, and a data area.
[0134] The determining part 1102 is used to determine the number of historical data records included in the data packet based on the value of the register count field and the preset register length of a single historical data record when the starting register address is the first starting register address. The first starting register address is used to indicate that the data packet is a historical data packet including a preset address.
[0135] The parsing section 1103 is used to cyclically parse the timestamps and running data of the specified number of historical data records from the data area;
[0136] Storage section 1104 is used to store runtime data based on timestamps.
[0137] In some embodiments, the storage portion 1104 is used to store running data in the data area based on the platform's current time when the starting register address is not the first starting register address.
[0138] In some embodiments, the parsing section 1103 is used to store the remaining data based on the platform's current time if there is remaining data in the data area after parsing out the number of historical data records from the data area.
[0139] In this embodiment, each part can implement the implementation steps corresponding to platform 130 in the above data processing system and achieve the same technical effect. To avoid repetition, it will not be described again here.
[0140] refer to Figure 12 , Figure 12 This is a schematic diagram of the hardware structure of an electronic device provided in an embodiment of this application. This electronic device can be implemented as either a terminal device 110 or a platform 130 (e.g., a server).
[0141] In some examples, the electronic device can be at least one of the following: a smartphone, a smartwatch, a desktop computer, a laptop, a virtual reality terminal, an augmented reality terminal, a wireless terminal, and a laptop computer. The electronic device has communication capabilities and can access wired or wireless networks. The term "electronic device" can refer to one of multiple terminals; those skilled in the art will understand that the number of such terminals can be more or less. It is understood that the electronic device performs the computational and processing work of the technical solution disclosed herein, and this disclosure does not limit this aspect.
[0142] like Figure 12 As shown, the electronic device in this disclosure may include one or more of the following components: processor 1210 and memory 1220.
[0143] Optionally, the processor 1210 connects various parts within the electronic device using various interfaces and lines. It executes various functions and processes data by running or executing instructions, programs, code sets, or instruction sets stored in the memory 1220, and by calling data stored in the memory 1220. Optionally, the processor 1210 can be implemented using at least one hardware form of Digital Signal Processing (DSP), Field Programmable Gate Array (FPGA), or Programmable Logic Array (PLA). The processor 1210 can integrate one or more of the following: Central Processing Unit (CPU), Graphics Processing Unit (GPU), Neural-network Processing Unit (NPU), and baseband chip. Specifically, the CPU primarily handles the operating system, user interface, and applications; the GPU is responsible for rendering and drawing the content displayed on the touchscreen; the NPU implements Artificial Intelligence (AI) functions; and the baseband chip handles wireless communication. It is understandable that the aforementioned baseband chip may not be integrated into the processor 1210, but may be implemented using a separate chip.
[0144] The memory 1220 may include random access memory (RAM) or read-only memory (ROM). Optionally, the memory 1220 may include a non-transitory computer-readable storage medium. The memory 1220 may be used to store instructions, programs, code, code sets, or instruction sets. The memory 1220 may include a program storage area and a data storage area, wherein the program storage area may store instructions for implementing an operating system, instructions for at least one function (such as touch function, sound playback function, image playback function, etc.), instructions for implementing the various method embodiments described above, etc.; the data storage area may store data created based on the use of the electronic device, etc.
[0145] In addition, those skilled in the art will understand that the structure of the electronic device shown in the above figures does not constitute a limitation on the electronic device. The electronic device may include more or fewer components than shown, or combine certain components, or have different component arrangements. For example, the electronic device may also include a display screen, camera assembly, microphone, speaker, radio frequency circuit, input unit, sensors (such as accelerometer, angular velocity sensor, light sensor, etc.), audio circuit, WiFi module, power supply, Bluetooth module, etc., which will not be described in detail here.
[0146] This disclosure also provides a computer-readable storage medium storing at least one instruction that is executed by a processor to implement the data processing methods described in the above embodiments.
[0147] This disclosure also provides a computer program product including computer instructions stored in a computer-readable storage medium; a processor of an electronic device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the electronic device to perform the data processing methods described in the above embodiments.
[0148] This disclosure also provides a chip, which includes a processor and a communication interface. The communication interface is coupled to the processor. The processor is used to run programs or instructions to implement the various processes of the above data processing method embodiments and achieve the same technical effect. To avoid repetition, it will not be described again here.
[0149] It should be understood that the chip mentioned in the embodiments of this disclosure may also be referred to as a system-on-a-chip, system chip, chip system, or system-on-a-chip, etc.
[0150] In the several embodiments provided in this disclosure, it should be understood that the disclosed systems, apparatuses, servers, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be an indirect coupling or communication connection between apparatuses or units through some interfaces, and may be electrical, mechanical, or other forms.
[0151] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.
[0152] Furthermore, the functional units in the various embodiments of this disclosure can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.
[0153] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this disclosure, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this disclosure. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, ROM, RAM, magnetic disks, or optical disks.
[0154] Those skilled in the art will recognize that the functions described in this disclosure in one or more of the examples above can be implemented using hardware, software, firmware, or any combination thereof. When implemented in software, these functions can be stored in a computer-readable medium or transmitted as one or more instructions or code on a computer-readable medium. Computer-readable media include computer storage media and communication media, wherein communication media include any medium that facilitates the transfer of a computer program from one place to another. Storage media can be any available medium accessible to a general-purpose or special-purpose computer.
[0155] It should be noted that the technical solutions described in this disclosure can be combined arbitrarily as long as they do not conflict.
[0156] The above description is merely a specific embodiment of this disclosure, but the scope of protection of this disclosure is not limited thereto. Any changes or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this disclosure should be included within the scope of protection of this disclosure.
Claims
1. A data processing method, characterized by, Applied to terminal devices, the data processing method includes: When the network connection between the terminal device and the platform is offline, the current running data and current timestamp generated by the terminal device are stored as a historical data record. When the network connection is restored to online status, a historical data packet is generated based on at least one historical data record. The historical data packet includes a first starting register address, a register count field, and a data area. The first starting register address is a preset address and is used to indicate that the data packet is a historical data packet including a timestamp. The data area includes the at least one historical data record. The value of the register count field represents the total number of registers occupied by all historical data records contained in the data area. The historical data messages are sent to the platform.
2. The data processing method according to claim 1, characterized in that, When the network connection is restored to online status, the generation of historical data packets based on at least one historical data record includes: Once the network connection is restored to online status, historical data packets are generated based on multiple historical data records.
3. The data processing method according to claim 1, characterized in that, The data processing method further includes: When the network connection status is online, a real-time data packet is generated. The real-time data packet includes a second starting register address and real-time collected running data. The second starting register address is different from the first starting register address. The real-time data message is sent to the platform.
4. The data processing method according to claim 1, characterized in that, The data processing method further includes: In the case where at least one historical data record is not sent to the platform and real-time data is generated, a mixed data message is generated based on at least one historical data record and real-time collected running data. The mixed data message includes the first starting register address, a register count field, and a data area. The data area includes at least one historical data record, a second starting register address, and real-time collected running data. The second starting register address is different from the first starting register address. The mixed data message is sent to the platform.
5. A data processing method, characterized in that, When applied to a platform, data processing methods include: The device receives a data packet sent by a terminal device, the data packet including a start register address, a register count field, and a data area; When the starting register address is the first starting register address, the number of historical data records included in the data packet is determined according to the value of the register count field and the preset register length of a single historical data record. The first starting register address is a preset address, and the first starting register address is used to indicate that the data packet is a historical data packet including a timestamp. The timestamps and running data of the specified number of historical data records are parsed from the data area in a loop, and the running data is stored based on the timestamps.
6. The data processing method according to claim 5, characterized in that, The data processing method further includes: If the starting register address is not the first starting register address, the running data in the data area is stored based on the current time of the platform.
7. The data processing method according to claim 5, characterized in that, The method further includes: After parsing the number of historical data records from the data area, if there is remaining data in the data area, the remaining data is stored based on the current time of the platform.
8. A data processing apparatus, characterized in that, The data processing device, applied to terminal devices, includes: The storage section is used to store the current running data and current timestamp generated by the terminal device as a historical data record when the network connection between the terminal device and the platform is offline. The processing section is used to generate a historical data packet based on at least one historical data record when the network connection status is restored to online status. The historical data packet includes a first starting register address, a register count field, and a data area. The first starting register address is a preset address and is used to indicate that the data packet is a historical data packet including a timestamp. The data area includes the at least one historical data record. The value of the register count field represents the total number of registers occupied by all historical data records contained in the data area. The sending section is used to send the historical data packets to the platform.
9. A data processing apparatus, characterized in that, The data processing device, applied to the platform, includes: The receiving section is used to receive data packets sent by the terminal device, wherein the data packets include a start register address, a register count field, and a data area; The determining part is used to determine the number of historical data records included in the data packet based on the value of the register count field and the preset register length of a single historical data record when the starting register address is a first starting register address. The first starting register address is a preset address and is used to indicate that the data packet is a historical data packet including a timestamp. In the parsing section, the timestamps and running data of the specified number of historical data records are parsed from the data area in a loop. The storage component stores the runtime data based on the timestamp.
10. A data processing system, characterized in that, The data processing system includes: at least one terminal device, a platform, and a communication network, wherein the at least one terminal device and the platform communicate through the communication network; The terminal device is configured to store the current running data and current timestamp generated by the terminal device as a historical data record when the network connection between the terminal device and the platform is offline. Furthermore, when the network connection status is restored to online status, a historical data packet is generated based on at least one historical data record. The historical data packet includes a first starting register address, a register count field, and a data area. The first starting register address is a preset address and is used to indicate that the data packet is a historical data packet including a timestamp. The data area includes the at least one historical data record, and the value of the register count field represents the total number of registers occupied by all historical data records contained in the data area. And, send the historical data packets to the platform; The platform is configured to receive data packets sent by a terminal device, the data packets including a start register address, a register count field, and a data area; And, when the starting register address is the first starting register address, the number of historical data records included in the data packet is determined according to the value of the register count field and the preset register length of a single historical data record; In addition, the timestamps and running data of the number of historical data records are parsed from the data area in a loop, and the running data is stored based on the timestamps.
Citation Information
Patent Citations
Allocating method and system of register addresses and related device
CN108280030A
Modbus protocol-based analysis method, device and system
CN112995133A