Data parsing methods, devices, equipment, media and products

Abstract

This application provides a data parsing method, apparatus, device, medium, and product. It receives data message frames sent by a water resources monitoring device. The data message frame includes a user data area, which comprises address field data, user data field data, and control field data. The address field data is parsed to obtain the station address of the water resources monitoring device. Based on the function code and station address in the control field data, a target parsing method for the user data field data is determined. The user data field data is then parsed into formatted data according to the target parsing method. The embodiments of this application can improve the data parsing efficiency of water resources monitoring devices.

Description

Technical Field

[0001] This application relates to the field of data processing technology, and in particular to a data parsing method, apparatus, device, medium, and product. Background Technology

[0002] With the rapid development of IoT technology, water resource monitoring has become a crucial link in achieving efficient water resource management and protection. Existing water resource monitoring systems often require multiple devices to handle complex monitoring tasks. However, differences in message formats between water resource monitoring devices from different manufacturers lead to cumbersome data parsing processes, resulting in low efficiency in data parsing. Summary of the Invention

[0003] This application provides a data parsing method, apparatus, equipment, medium, and product that can improve the data parsing efficiency of water resource monitoring equipment.

[0004] In a first aspect, embodiments of this application provide a data parsing method applied to an Internet of Things (IoT) system, the method comprising:

[0005] Receive data message frames sent by water resource monitoring equipment. The data message frame includes a user data area, which includes address field data, user data field data, and control field data.

[0006] The address field data is parsed to obtain the station address of the water resource monitoring equipment;

[0007] Based on the function code and station address in the control domain data, determine the target parsing method for the user data domain data;

[0008] The user data domain data is parsed into formatted data according to the target parsing method.

[0009] Secondly, this application provides a data parsing device for use in an Internet of Things (IoT) system, the device comprising:

[0010] The receiving module is used to receive data message frames sent by the water resources monitoring equipment. The data message frame includes a user data area, which includes address field data, user data field data, and control field data.

[0011] The first parsing module is used to parse the address field data to obtain the station address of the water resource monitoring equipment;

[0012] The determination module is used to determine the target parsing method of the user data domain data based on the function code and station address in the control domain data;

[0013] The second parsing module is used to parse user data field data into formatted data according to the target parsing method.

[0014] Thirdly, embodiments of this application provide an electronic device, which includes: a processor and a memory storing computer program instructions;

[0015] When the processor executes computer program instructions, it implements the data parsing method as described in any of the embodiments of the first aspect.

[0016] Fourthly, embodiments of this application provide a computer storage medium storing computer program instructions, which, when executed by a processor, implement the data parsing method as described in any of the embodiments of the first aspect.

[0017] Fifthly, embodiments of this application provide a computer program product in which instructions, when executed by a processor of an electronic device, cause the electronic device to perform a data parsing method as described in any of the embodiments of the first aspect above.

[0018] In a data parsing method, apparatus, device, medium, and product provided in this application embodiment, a data message frame sent by a water resource monitoring device is first received, which includes address field data, user data field data, and control field data. By parsing the address field data, the system can accurately identify the station address of each water resource monitoring device, providing a foundation for subsequent data parsing. Next, based on the function code and station address in the control field data, the system can determine the specific parsing method for the user data field data. This step fully considers the differences in message formats among different water resource monitoring devices, enabling the system to flexibly adapt to the access requirements of various water resource monitoring devices. Finally, according to the determined target parsing method, the system parses the user data field data into formatted data, allowing the data to be stored and analyzed in a unified and standardized form. This process simplifies the complexity of data parsing, thereby improving the data parsing efficiency of the water resource monitoring device. Attached Figure Description

[0019] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments of this application will be briefly introduced below. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0020] Figure 1 This is a flowchart illustrating a data parsing method provided in one embodiment of this application;

[0021] Figure 2 This is a schematic diagram of the data structure of a data packet frame provided in one embodiment of this application;

[0022] Figure 3This is a schematic diagram of a login process provided in one embodiment of this application;

[0023] Figure 4 This is a schematic diagram of a logout process provided in one embodiment of this application;

[0024] Figure 5 This is a schematic diagram of a keep-alive process provided in one embodiment of this application;

[0025] Figure 6 This is a schematic diagram of a data structure for control domain data provided in one embodiment of this application;

[0026] Figure 7 This is a schematic diagram of the data structure of address field data provided in one embodiment of this application;

[0027] Figure 8 This is a schematic diagram of another address field data data provided in one embodiment of this application;

[0028] Figure 9 This is a flowchart illustrating another data parsing method provided in one embodiment of this application;

[0029] Figure 10 This is a flowchart illustrating another data parsing method provided in one embodiment of this application;

[0030] Figure 11 This is a schematic diagram of the structure of a data parsing device provided in an embodiment of this application;

[0031] Figure 12 This is a schematic diagram of the structure of the electronic device provided in the embodiments of this application. Detailed Implementation

[0032] To better understand the above-mentioned objectives, features, and advantages of this disclosure, the solutions disclosed herein will be further described below. It should be noted that, unless otherwise specified, the embodiments and features described herein can be combined with each other.

[0033] Numerous specific details are set forth in the following description in order to provide a full understanding of this disclosure, but this disclosure may also be implemented in other ways different from those described herein; obviously, the embodiments in the specification are only some, and not all, of the embodiments of this disclosure.

[0034] It should be noted that, in this document, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the term "comprising" or any other variations thereof is intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes the element.

[0035] Currently, most IoT platforms primarily support mainstream access protocols such as Message Queuing Telemetry Transport Protocol (MQTT), Lightweight Machine-to-Machine (Lwm2m) protocol, and Hypertext Transfer Protocol (HTTP). However, they do not directly connect water resource monitoring devices to IoT platforms. This necessitates considering how to convert the messages from water resource monitoring devices into access protocols supported by the IoT platform. This requires understanding the differences between the two protocols and learning their encoding and decoding methods, resulting in significant user integration costs. Furthermore, most water resource device access systems only support a single water resource monitoring function, or even only a single type of water resource monitoring device. Adapting to other monitoring function requirements or other types of water resource monitoring device access will consume considerable time.

[0036] The existing technology has the following main drawbacks:

[0037] 1. Water resource monitoring services or systems are functionally limited, providing only single-function data reporting or analysis. The water resource monitoring data transmission protocol includes dozens of application-layer functions, with the uplink self-reporting frames defining approximately a dozen types of water resource data, such as rainfall, water level, flow rate, and flow velocity. Single-function data reporting or analysis cannot meet the needs of monitoring diverse water resource data.

[0038] 2. Water resource monitoring services or systems only provide access to specific water resource monitoring equipment. Different manufacturers' water resource monitoring equipment may have custom messages. This poses a significant limitation for connecting water resource monitoring equipment from different manufacturers to a unified IoT platform. It is necessary to adapt to the custom messages of each manufacturer, which greatly reduces the efficiency of connecting to a unified IoT platform and increases the workload of adapting custom messages.

[0039] To address the problems existing in the prior art, embodiments of this application provide a data parsing method, apparatus, device, medium, and product.

[0040] This application provides a data parsing method, apparatus, device, medium, and product. The data parsing method provided in this application will be described first. For example... Figure 1 As shown, this method is applied to an Internet of Things (IoT) system, and specifically includes the following steps:

[0041] S100, receive a data message frame sent by a water resources monitoring device. The data message frame includes a user data area, which includes address field data, user data field data, and control field data.

[0042] Optionally, in this embodiment of the application, the Internet of Things system includes a device access module, a message frame preprocessing module, and a data parsing module.

[0043] Optionally, in the embodiments of this application, the data structure format of the data packet frame is as follows: Figure 2 As shown, a data packet frame includes a fixed-length header (i.e., the header area), a user data area, a frame check area, and a byte count character area (i.e., the byte count character area). "68H" and "16H" are hexadecimal data.

[0044] In some embodiments, the user data area is a portion of the data packet frame and is primarily used to store user-related data. The address field data is a portion of the data packet frame used to identify the source or destination device of the data. In water resource monitoring equipment applications, the address field data represents the address or ID of the monitoring equipment sending the data.

[0045] In some embodiments, water resource monitoring equipment is used to monitor the operation of water conservancy facilities such as rivers and lakes. It detects various water parameters, such as temperature, humidity, wind speed, wind direction, rainfall, water quality, water flow velocity, and water volume, through various detectors, such as radar flow meters, radar current meters, radar water level meters, and water quality sensors.

[0046] In some embodiments, the user data domain is the core part of the user data area, containing the actual transmitted data content. This data includes various parameter values, status information, or other user-related data collected from the monitoring equipment. In the scenario of water resource monitoring equipment, the user data domain includes water level readings, water quality parameter values, equipment status information, etc.

[0047] In some embodiments, control domain data is used to instruct the receiving end (i.e., the IoT system) how to process data in the user data domain. It includes control commands, operating instructions, or other information to guide data processing. In water resource monitoring equipment applications, control domain data is used to instruct the receiving end how to store data, whether a response needs to be sent, whether a certain operation needs to be performed, etc.

[0048] In some embodiments, firstly, it is ensured that the water resource monitoring equipment has successfully established a communication connection with the Internet of Things (IoT) system. This can be achieved through Transmission Control Protocol / Internet Protocol (TCP / IP) or other applicable communication protocols. Once the connection is established, the IoT system begins listening for data transmissions from the water resource monitoring equipment. When the monitoring equipment sends data message frames, the IoT system can accurately receive these data message frames.

[0049] Optionally, in one feasible implementation of this application, firstly, it is necessary to clarify the communication protocol used by the water resource monitoring equipment and understand its key elements such as data transmission mechanism, frame structure, and error handling. Then, according to the requirements of the communication protocol, the network parameters of the IoT system's receiving end, such as IP address and port number, are configured. After the IoT system's receiving end successfully establishes a communication connection with the water resource monitoring equipment, when the IoT system's receiving end receives a data packet frame sent by the water resource monitoring equipment, if an error (such as a frame format error) is encountered during the reception of the data packet frame, it needs to be handled according to the error handling mechanism of the communication protocol. An error response or a re-request for data is then sent to the sending end (i.e., the water resource monitoring equipment). To facilitate subsequent data analysis and troubleshooting, key information such as the received data packet frames, parsing results, and processing procedures can be recorded in a log.

[0050] Optionally, in one specific implementation of this application, the device access module of the Internet of Things system includes login, logout, and keep-alive functions.

[0051] The login process is as follows: Figure 3 As shown, the specific steps include:

[0052] The terminal device (i.e., water resource monitoring device) connects to a specific port that the device access module listens to via Transmission Control Protocol (TCP), and the device establishes a TCP connection with the module.

[0053] After the initial TCP connection is established, the device access module carries a message frame for sending link monitoring (02H) to the terminal device, in which the data field contains F0 login.

[0054] After receiving the message, the terminal device replies with a confirmation message from the device access module, in which the data field includes F0 login.

[0055] When the device access module receives a confirmation message containing F0 login in the data field, it determines whether a session for the terminal device information already exists in the device access module. If it does not exist, it creates a session for the terminal device information. If it exists, it is considered a duplicate login, so the device information session for the terminal is removed from the access module, and the TCP connection with the terminal device is disconnected.

[0056] The logout process is as follows: Figure 4 As shown, the specific steps include:

[0057] The terminal device successfully established a TCP connection with the device access module. The device access module then sends a link monitoring (02H) message frame to the terminal device, in which the data field includes F1 logout.

[0058] After receiving the message, the terminal device replies with a confirmation message frame to the device access module, in which the data field includes F1 logout;

[0059] After receiving a confirmation message frame containing F1 logout data in the data field, the device access module removes the session containing the terminal device information in the device access module and actively disconnects the TCP connection with the terminal device.

[0060] The survival process is as follows: Figure 5 As shown, the specific steps include:

[0061] The terminal device successfully established a TCP connection with the device access module. The device access module then sends a link monitoring (02H) message frame to the terminal device, in which the data field includes F2 keep-alive.

[0062] After receiving the message, the terminal device replies with a confirmation message frame from the device access module, in which the data field contains F2 login, protection and activation.

[0063] After receiving an acknowledgment frame containing F2 keep-alive in the data field, the device access module maintains the session of the terminal device information in the device access module. If the terminal device does not reply with an acknowledgment frame containing F2 keep-alive in the data field within the keep-alive time set by the device access module, the device access module considers the terminal device to be invalid, removes the session of the terminal device information in the device access module, and actively disconnects the TCP connection with the terminal device.

[0064] Optionally, in this embodiment, after the terminal device successfully establishes a TCP connection with the device access module, the terminal device sends a data packet frame to the message frame preprocessing module of the Internet of Things system.

[0065] S200, the address field data is parsed to obtain the station address of the water resource monitoring equipment.

[0066] Optionally, in this embodiment of the application, the station address is used to uniquely identify different monitoring stations in the water resource monitoring equipment. Since multiple monitoring stations may simultaneously send data to the receiving end, the station address is needed to distinguish the data sent by different stations. The station address is included in the address field data, and the receiving end can determine the source of the data based on the station address when parsing the data, and associate the data with the corresponding monitoring station.

[0067] Optionally, in this embodiment, the function code is an important component in the control field of the data packet frame. It indicates the specific operation the device should perform or the nature of the data. Different function codes may correspond to different data types, data formats, and data parsing methods. By recognizing the function code, the receiving end can understand the operation the sending end intends to perform and thus take appropriate processing measures.

[0068] Optionally, in one feasible implementation of this application, firstly, the location of the address field data can be accurately located within the received data packet frame, depending on the specific format and protocol specifications of the data packet frame. Then, the encoding method used for the address field data is determined (e.g., American Standard Code for Information Interchange (ASCII), Binary-Coded Decimal (BCD), Hexadecimal Encoding (or Hexadecimal, HEX code), etc.). Subsequently, based on the encoding method, the specific numerical value or character is extracted from the address field data. If the extracted data is not directly presented in the form of a station address, format conversion or decoding operations can be performed to obtain readable station address information.

[0069] The parsed station addresses can then be verified to ensure they conform to the expected format and range. Specifically, checksums and other verification mechanisms can be used to ensure data integrity and accuracy. Finally, the parsed and verified station address information is stored in an appropriate location (such as a database or memory) for later use.

[0070] S300, determine the target parsing method of the user data domain data based on the function code in the control domain data and the station address.

[0071] Optionally, in this embodiment, the function code is an important component in the control field of the data packet frame. It indicates the specific operation the device should perform or the nature of the data. Different function codes may correspond to different data types, data formats, and data parsing methods. By recognizing the function code, the receiving end can understand the operation the sending end intends to perform and thus take appropriate processing measures.

[0072] Optionally, in one implementation of this application, the function code is first extracted from the control field of the received data message frame. Then, based on known communication protocols or specifications, the specific meaning represented by the function code is understood. Different function codes correspond to different data types, data formats, and data parsing methods. Considering that some systems allow different station addresses to use different data formats or parsing methods, the station address can be used as auxiliary information to determine the target parsing method. However, this is not necessary for all systems and depends on the specific communication protocol or system design. Subsequently, combining the meaning of the function code and (if necessary) station address information, the target parsing method for the user data field data is determined. Specifically, this may include determining the data type (e.g., integer, floating-point number, string, etc.), data length, data encoding method (e.g., ASCII, BCD, HEX, etc.), data unit, data scaling factor, etc.

[0073] S400, the user data domain data is parsed into formatted data according to the target parsing method.

[0074] Optionally, in one feasible implementation of this application, firstly, the data format in the user data field is determined according to the target parsing method. This specifically includes the data type (e.g., integer, floating-point number, string, etc.), data length, byte order (big-endian or little-endian), etc. Then, the data to be parsed is extracted from the user data field. Specifically, this involves reading data from a byte stream according to a specified length and order. Subsequently, the data is decoded and converted according to the data format. For example, if the data is binary encoded, it can be converted to a decimal number; if the data is compressed, decompression operations can be performed.

[0075] If the data in the user data domain is represented in a specific unit or scaling factor, unit conversion and scaling can be performed to obtain the actual value. For example, temperature data may be represented in Celsius but needs to be converted to Fahrenheit; or flow data may be represented in some scaling factor and needs to be multiplied by that factor to obtain the actual flow rate.

[0076] The parsed data can then be validated to ensure its accuracy and completeness. This can specifically include checking the data's range, precision, and consistency.

[0077] The parsed data can then be output in the desired format. This may include converting the data to a string, adding labels or units, and adjusting the data format (such as retaining decimal places). Finally, the formatted data can be stored in an appropriate location (such as a database, file, or memory) for later use.

[0078] In a data parsing method, apparatus, device, medium, and product provided in this application embodiment, a data message frame sent by a water resource monitoring device is first received, which includes address field data, user data field data, and control field data. By parsing the address field data, the system can accurately identify the station address of each water resource monitoring device, providing a foundation for subsequent data parsing. Next, based on the function code and station address in the control field data, the system can determine the specific parsing method for the user data field data. This step fully considers the differences in message formats among different water resource monitoring devices, enabling the system to flexibly adapt to the access requirements of various water resource monitoring devices. Finally, according to the determined target parsing method, the system parses the user data field data into formatted data, allowing the data to be stored and analyzed in a unified and standardized form. This process simplifies the complexity of data parsing, thereby improving the data parsing efficiency of the water resource monitoring device.

[0079] In one embodiment, the data packet frame further includes a header area and a frame check area; prior to step 200 above, the method may further perform the following steps:

[0080] S201, parse the message header area to obtain a valid result of the data message frame;

[0081] S202, if the valid result indicates that the data packet frame is valid, the data packet frame is verified according to the check code of the frame check area to obtain the verification result of the data packet frame;

[0082] In one embodiment, step 200 above may specifically be performed as follows:

[0083] S210, if the verification result is that the data packet frame verification is successful, the address field data is parsed to obtain the station address of the water resource monitoring equipment.

[0084] Optionally, in this embodiment, the message header contains metadata required for information exchange between the sender and receiver. This metadata is used for purposes such as routing, identification, control, and authentication during transmission. Specifically, the message header may contain at least the following:

[0085] Source and destination address information: Used to indicate the sender and receiver of the message, as well as the routing path the message traversed. Specific identifiers: Such as protocol version number, sequence number, acknowledgment number, etc., used to identify message type, order, retransmission, and acknowledgment information. Control information: Such as window size, priority flags, etc., used to control message transmission behavior, flow control, and congestion control. Security information: Such as encryption, authentication, digital signatures, etc., to ensure the confidentiality, integrity, and reliability of data transmission. Extended fields: Used to support new features or protocols that may emerge in the future, to better adapt to the ever-changing network environment.

[0086] Optionally, in this embodiment, the message header may also include data length information for the data message frame. This data length field indicates the actual data length of the subsequent user data area, helping the receiving end to correctly parse and process the received data. By knowing the data length, the receiving device can determine when the reception of the entire data frame is complete and can check whether the received data is complete. If the data length does not match the actual amount of data received, the receiving end may request retransmission of data or take other error handling measures. This field is crucial for ensuring the integrity and accuracy of the data.

[0087] Optionally, in this embodiment, the frame checksum is used to ensure the integrity and accuracy of data during transmission. It calculates a checksum by using the checksum of all bytes in the data frame except the frame preamble or other verification algorithms, and appends this value to the end of the data frame. Upon receiving the data frame, the receiving end recalculates the checksum of all bytes in the data frame except the frame preamble and the frame checksum sequence, and compares it with the received frame checksum sequence. If they match, it indicates that no errors occurred during data transmission; otherwise, the receiving end discards the data frame and requests the sending end to retransmit it.

[0088] Optionally, in one feasible implementation of this application, firstly, in step S201, the receiving end parses the header area of ​​the data packet frame. By parsing this metadata, the receiving end can determine whether the data packet frame is valid, that is, whether it conforms to the expected communication protocol and data format.

[0089] Next, in step S202, if the data packet frame is determined to be valid, the receiving end will further verify the data packet frame based on the checksum in the frame check area. The frame check area contains a Cyclic Redundancy Check (CRC) value calculated by the sending end. The receiving end will recalculate the CRC value of the entire data packet frame (except for the frame check area itself) and compare it with the CRC value in the frame check area. If the two match, it means that no errors occurred in the data packet frame during transmission, and the verification result is successful; otherwise, the verification result is unsuccessful.

[0090] Finally, in step S210, if the data packet frame verification result is successful, the receiving end will begin parsing the address field data of the data packet frame. By parsing the address field data, the receiving end can obtain the unique identifier of the water resource monitoring equipment that sent the data packet frame, i.e., the station address.

[0091] In these alternative embodiments, parsing the message header helps identify the validity of data packet frames, preventing invalid data from being further processed. Secondly, frame checksum verification can detect errors that may occur during transmission, such as bit flips or losses, thereby ensuring the integrity of the data packet frame. Only when the message header is valid and the frame checksum passes will the address field data be parsed to obtain the station address of the water resources monitoring equipment. This process design not only improves the efficiency of data processing but also enhances the reliability of data transmission, providing a strong guarantee for the stable operation of the water resources monitoring system.

[0092] In one embodiment, the data packet frame further includes an end character area; step 201 above can specifically be performed as follows:

[0093] S2011, parse the message header area to obtain the byte content of the first byte, second byte and third byte of the message header area;

[0094] S2012, obtain the length of the first byte in the data frame excluding the header area, and the total byte length of the user data area, the frame check area, and the end character area;

[0095] S2013, when the byte content of the first byte matches the first preset content, and the byte content of the third byte matches the second preset content, and the length of the first byte is equal to the total byte length, the valid result is determined as the first result, and the first result indicates that the data packet frame is valid;

[0096] S2014, if the first condition is met, the valid result is determined as the second result, and the second result indicates that the data packet frame is invalid;

[0097] The first condition includes at least one of the following:

[0098] The byte content of the first byte does not match the first preset content;

[0099] The content of the third byte does not match the second preset content;

[0100] The length of the first byte is not equal to the total byte length.

[0101] Optionally, in one specific implementation of this application, such as Figure 9 As shown, the terminal device successfully established a TCP connection with the device access module. The terminal device then sent a data packet frame to the packet frame preprocessing module.

[0102] When the message frame preprocessing module receives a data message frame initiated by the terminal device, it first parses the fixed header (i.e., the message header area) of the data message frame.

[0103] The first byte (i.e., the first byte) of the fixed header of the data packet frame is obtained. If the first byte of the header is 68H, the second byte (i.e., the second byte) of the data packet frame is obtained. The content of the second byte is the data length. If the first byte of the header is not 68H, the data packet frame is discarded and a data packet frame error is replied to the terminal device.

[0104] Subsequently, if the header start byte is 68H, the third byte (i.e., the third byte) of the fixed header of the data packet frame is obtained, which is the tail start byte. If the tail start byte is 68H, the data packet frame parsing continues; if the tail start byte is not 68H, the data packet frame is discarded and a data packet frame error is replied to the terminal device.

[0105] Subsequently, with the starting byte at the end being 68H, the remaining bytes of the data packet frame excluding the fixed header (i.e., the length of the first byte) are obtained. If the length of the remaining bytes is not equal to the sum of the user data area, frame check area, and end character (i.e., the total byte length), the data packet frame is discarded, and a data packet frame reporting error is replied to the terminal device. If the length of the remaining bytes is equal to the sum of the user data area, frame check area, and end character, the next step of data packet frame parsing is continued.

[0106] In these optional embodiments, by matching the key bytes of the message header with preset content, the data message frame is ensured to conform to the expected protocol format. Secondly, the lengths of each region in the data frame are calculated and compared to ensure data integrity and consistency. Only when all conditions are met is a valid result determined as the first result indicating the validity of the data message frame. Any mismatch or inconsistent length will result in the data message frame being considered invalid. This design effectively filters out non-compliant data message frames, improving the efficiency and accuracy of data processing and providing strong support for the stable operation of the water resources monitoring system.

[0107] In one embodiment, the byte content of the second byte includes the data length of each data area in the data packet frame; step 202 above can specifically be performed as follows:

[0108] S2021, Based on the data length of each data area in the data packet frame, obtain the check code of the frame check area and the byte content of the user data area;

[0109] S2022, Perform verification calculation on the byte content of the user data area to obtain the calculation result;

[0110] S2023, if the calculation result matches the check code, the check result is determined as the third result, and the third result indicates that the data packet frame has passed the check.

[0111] S2024, if the calculation result does not match the check code, the check result is determined as the fourth result, and the fourth result indicates that the data packet frame check fails.

[0112] Optionally, in one specific implementation of this application, the byte content of the user data area and the CRC content of the frame check area are obtained according to the length of the obtained data.

[0113] Subsequently, based on the byte content of the user data area, a CRC calculation is performed. The generator polynomial rule for the CRC calculation is: X 7 +X 6 +X 5 +X 2 +1 (where different powers of X in the CRC algorithm represent different positions in the binary number), and compare the calculated CRC result of the user data area with the CRC content in the acquired message frame. If the calculated CRC result of the user data area does not match the CRC content of the frame check area in the acquired data message frame, the message frame is discarded, and a message frame data field check error is reported to the device. If the calculated results match, the next step of message frame parsing is performed.

[0114] In these optional embodiments, the checksum of the frame verification area and the byte content of the user data area are correctly obtained using the byte content of the second byte, i.e., the data length of each data area. Subsequently, in step S2022, the system performs a checksum calculation on the byte content of the user data area and compares the calculation result with the checksum. Only when the two match is the data packet frame verification considered successful; otherwise, the verification fails. This verification method improves the reliability of data transmission and ensures data integrity, which is of great significance for water resource monitoring systems that require high-reliability transmission.

[0115] In one embodiment, step 200 above may specifically be performed as follows:

[0116] S220, if the byte content of the first byte of the address field data does not match the third preset content, perform data conversion on the last two bytes of the address field data to obtain the station address;

[0117] S230, if the byte content of the first byte of the address field data matches the third content, perform data conversion on the last four bytes of the address field data according to a preset conversion method to obtain the station address.

[0118] Optionally, in one specific implementation of this application, the message content in the control field data is first parsed, from the most significant bit D7 to the least significant bit D0 in the byte, and the control field structure is defined as follows: Figure 6 As shown.

[0119] Among them, the transmission direction bit DIR: the highest bit D7 of the control field, 0-downlink, 1-uplink;

[0120] Split flag DIV: Control field D6 bit, 0 - single frame, 1 - multiple frames;

[0121] Frame Count Bit (FCB): Control field bits D5-D4, for each failed send / acknowledgment or request / response.

[0122] Function codes: Control fields D3-D0, with different function code definitions depending on the function code table.

[0123] Subsequently, the message content in the address field data of the user data area is parsed. The address field data has a fixed length of 5 bytes and can be executed in one of two ways.

[0124] First, check if the first byte of the address field data is 00H. If it is not 00H, then proceed as follows: Figure 7 The address field is parsed using the method shown; if it is 00H, then it is parsed as follows: Figure 8 The address field resolution method shown is used for parsing.

[0125] Specifically, if the first byte of the address field data is not 00H, the first three bytes of the address field data are taken and directly converted into a 6-digit hexadecimal string. Since BCD encoding uses 4 binary digits to represent 1 decimal digit (0-9), the 6-digit hexadecimal string represents the value of 6 decimal digits. Therefore, the first two digits of the converted 6-digit hexadecimal string are the province (region, city) code, the middle two digits are the prefecture (city) code, and the last two digits are the county (district) code. The last two bytes of the address field data are taken. The two bytes of the station and relay station address consist of binary data, which is converted into a decimal value. The station address range is 1-60000. The relay station address range is 60001-65534. 65535 is the broadcast address, and 0 is an invalid address.

[0126] If the first byte of the address field is 00H, then according to Figure 8 The address is parsed using the method shown. The first byte 90H hydrological feature code is skipped directly. The next 4 bytes are read and converted into an 8-bit HEX code as the hydrological station code according to the "Hydrological Station Coding" of the Hydrological Bureau of the Ministry of Water Resources.

[0127] like Figure 9 As shown in a complete embodiment, the specific processing flow of the message frame preprocessing module of the Internet of Things system is as follows:

[0128] S1: The terminal device successfully established a TCP connection with the device access module. The terminal device then sends a data packet frame to the packet frame preprocessing module.

[0129] S2: When the message frame preprocessing module receives a data message frame initiated by the terminal device, it first parses the fixed header of the data message frame.

[0130] S3: Obtain the remaining bytes of the data packet frame excluding the fixed header. If the length of the remaining bytes is not equal to the sum of the length of the user data area, the frame check area, and the end character, discard the data packet frame and reply to the terminal device with a data packet frame reporting error. If the length of the remaining bytes is equal to the sum of the length of the user data area, the frame check area, and the end character, continue to the next step of data packet frame parsing.

[0131] S4: Based on the data length obtained in S2, obtain the byte content of the user data area;

[0132] S5: Obtain the contents of the frame check area;

[0133] S6: Based on the byte content of the user data area, perform CRC calculation. Compare the calculated CRC result of the user data area with the CRC content in the message frame obtained in S5. If the calculated CRC result of the user data area does not match the CRC content in the message frame obtained in S5, discard the message frame and reply to the device with a message frame data field verification error. If the calculated results match, proceed to the next step of message frame parsing.

[0134] S7: Parse the message content in the user data area control field.

[0135] S8: Parse the message content in the address field of the user data area. The address field has a fixed length of 5 bytes and is executed in one of two ways.

[0136] S9: The message frame preprocessing module sends the subsequent user data field data to the data parsing module for subsequent data parsing.

[0137] In these optional embodiments, when the first byte of the address field data does not conform to expectations (i.e., does not match the third preset content), the system only converts the last two bytes of the address field data to obtain the station address. Conversely, when the first byte matches the preset content, the system converts the last four bytes of the address field data according to another preset conversion method. This dual processing method ensures the accuracy of data conversion while improving processing flexibility, enabling the system to adapt to address data of different formats, thereby obtaining the station address of water resource monitoring equipment more efficiently and accurately.

[0138] In one embodiment, step 300 above may specifically be performed as follows:

[0139] S310, if the function code matches the fourth preset content stored in the database, retrieve the target parsing method corresponding to the function code from the database;

[0140] S320, if the function code does not match the fourth preset content stored in the database, obtain the target parsing method corresponding to the function code and the station address.

[0141] Optionally, in one specific implementation of this application, such as Figure 10 As shown, the message frame preprocessing module sends the preprocessed terminal device user data field data to the data parsing module.

[0142] The function code is obtained from the first byte of the control domain data. It is then determined whether the function code exists in the system. If it does, the corresponding parsing process is followed according to the system. After parsing, the formatted data is stored in the database. If it does not exist in the system, it is a user-defined function code. In this case, the user data parsing script corresponding to the function code and the station address can be obtained from the system.

[0143] If the user-edited data parsing script corresponding to the function code and station address does not exist, the data in the user data field will be stored in the database in its raw form. If the user-edited data parsing script corresponding to the function code and station address exists, the script will be invoked to parse the data to be parsed in the user data field into formatted data, which will then be stored in the database.

[0144] In these optional embodiments, these steps achieve dynamic selection and acquisition of the target parsing method through the association and matching of function codes with preset content and station addresses. When the function code matches the fourth preset content stored in the database, the system can directly obtain the corresponding target parsing method from the database, improving processing efficiency. When the function code does not match, the system can further determine and obtain the corresponding target parsing method based on the comprehensive information of the function code and the station address, which increases the system's flexibility and adaptability. This design enables the system to intelligently select the parsing method according to different situations, thereby more accurately parsing and processing the received data packet frames, improving the accuracy and reliability of data processing.

[0145] Figure 11 A schematic diagram of the structure of a data parsing apparatus provided in another embodiment of this application is shown. For ease of explanation, only the parts related to the embodiments of this application are shown.

[0146] Reference Figure 11 The data parsing device is used in Internet of Things (IoT) systems and may include:

[0147] The receiving module 1101 is used to receive data message frames sent by water resource monitoring equipment. The data message frame includes a user data area, which includes address field data, user data field data, and control field data.

[0148] The first parsing module 1102 is used to parse the address field data to obtain the station address of the water resource monitoring equipment;

[0149] The determination module 1103 is used to determine the target parsing method of the user data domain data based on the function code in the control domain data and the station address;

[0150] The second parsing module 1104 is used to parse the user data domain data into formatted data according to the target parsing method.

[0151] In one embodiment, the data packet frame further includes a header area and a frame check area; the data parsing device may further include:

[0152] The first parsing submodule is used to parse the message header area to obtain a valid result of the data message frame;

[0153] The verification submodule is used to verify the data packet frame according to the check code in the frame verification area when the valid result indicates that the data packet frame is valid, and to obtain the verification result of the data packet frame.

[0154] In one embodiment, the first parsing module may include:

[0155] The second parsing submodule is used to parse the address field data to obtain the station address of the water resources monitoring equipment when the verification result is that the data packet frame verification is successful.

[0156] In one embodiment, the data packet frame further includes an end-of-line character area; the first parsing submodule may include:

[0157] The first parsing unit is used to parse the message header area to obtain the byte content of the first byte, the second byte, and the third byte of the message header area;

[0158] The first acquisition unit is used to acquire the length of the first byte in the data frame excluding the message header area, and the total byte length of the user data area, the frame check area and the end character area;

[0159] The first determining unit is configured to determine the valid result as a first result when the byte content of the first byte matches the first preset content, the byte content of the third byte matches the second preset content, and the length of the first byte is equal to the total byte length. The first result indicates that the data packet frame is valid.

[0160] The second determining unit is configured to determine the valid result as the second result if the first condition is met, wherein the second result indicates that the data packet frame is invalid;

[0161] The first condition includes at least one of the following:

[0162] The byte content of the first byte does not match the first preset content;

[0163] The content of the third byte does not match the second preset content;

[0164] The length of the first byte is not equal to the total byte length.

[0165] In one embodiment, the byte content of the second byte includes the data length of each data area in the data packet frame; the verification submodule may include:

[0166] The third determining unit is used to obtain the check code of the frame check area and the byte content of the user data area based on the data length of each data area in the data packet frame.

[0167] The first calculation unit is used to perform verification calculations on the byte content of the user data area and obtain the calculation results.

[0168] The fourth determining unit is configured to determine the verification result as a third result if the calculation result matches the verification code, wherein the third result indicates that the data packet frame verification has passed;

[0169] The fifth determining unit is used to determine the verification result as the fourth result when the calculation result does not match the check code, and the fourth result indicates that the data packet frame verification fails.

[0170] In one embodiment, the first parsing module 1102 may further include:

[0171] The first conversion submodule is used to perform data conversion on the last two bytes of the address field data to obtain the station address when the byte content of the first byte of the address field data does not match the third preset content.

[0172] The second conversion submodule is used to perform data conversion on the last four bytes of the address field data according to a preset conversion method when the byte content of the first byte of the address field data matches the third content, so as to obtain the station address.

[0173] In one embodiment, the determining module 1103 may further include:

[0174] The first acquisition submodule is used to acquire the target parsing method corresponding to the function code from the database when the function code matches the fourth preset content stored in the database.

[0175] The second acquisition submodule is used to acquire the target parsing method corresponding to the function code and the station address when the function code does not match the fourth preset content stored in the database.

[0176] It should be noted that the information interaction and execution process between the above-mentioned devices / units are based on the same concept as the method embodiments of this application. They are devices corresponding to the above-mentioned battery thermal runaway early warning method. All implementation methods in the above-mentioned method embodiments are applicable to the embodiments of this device. For details on its specific functions and the technical effects it brings, please refer to the method embodiment section. It will not be repeated here.

[0177] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is merely an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiments 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. Furthermore, the specific names of the functional units and modules are only for easy differentiation and are not intended to limit the scope of protection of this application. The specific working process of the units and modules in the above system can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0178] Figure 12 A schematic diagram of the hardware structure of the electronic device provided in an embodiment of this application is shown.

[0179] The device may include a processor 1201 and a memory 1202 storing program instructions.

[0180] When processor 1201 executes the program, it implements the steps in any of the above method embodiments.

[0181] For example, the program can be divided into one or more modules / units, one or more of which are stored in memory 1202 and executed by processor 1201 to complete this application. The one or more modules / units can be a series of program instruction segments capable of performing a specific function, which describe the execution process of the program in the device.

[0182] Specifically, the processor 1201 may include a central processing unit (CPU), an application-specific integrated circuit (ASIC), or one or more integrated circuits that can be configured to implement the embodiments of this application.

[0183] Memory 1202 may include mass storage for data or instructions. For example, and not limitingly, memory 1202 may include a hard disk drive (HDD), floppy disk drive, flash memory, optical disk, magneto-optical disk, magnetic tape, or Universal Serial Bus (USB) drive, or a combination of two or more of these. Where appropriate, memory 1202 may include removable or non-removable (or fixed) media. Where appropriate, memory 1202 may be internal or external to the integrated gateway disaster recovery device. In a particular embodiment, memory 1202 is non-volatile solid-state memory.

[0184] Memory may include read-only memory (ROM), random access memory (RAM), disk storage media devices, optical storage media devices, flash memory devices, and electrical, optical, or other physical / tangible memory storage devices. Therefore, typically, memory includes one or more tangible (non-transitory) readable storage media (e.g., memory devices) encoded with software including computer-executable instructions, and when the software is executed (e.g., by one or more processors), it is operable to perform the operations described with reference to the methods according to one aspect of this disclosure.

[0185] The processor 1201 implements any of the methods described in the above embodiments by reading and executing program instructions stored in the memory 1202.

[0186] In one example, the electronic device may also include a communication interface 1203 and a bus 1210. The processor 1201, memory 1202, and communication interface 1203 are connected via the bus 1210 and communicate with each other.

[0187] The communication interface 1203 is mainly used to realize communication between various modules, devices, units and / or equipment in the embodiments of this application.

[0188] Bus 1210 includes hardware, software, or both, that couples components of an online data traffic metering device together. For example, and not limitingly, the bus may include an Accelerated Graphics Port (AGP) or other graphics bus, an Enhanced Industry Standard Architecture (EISA) bus, a Front Side Bus (FSB), HyperTransport (HT) interconnect, an Industry Standard Architecture (ISA) bus, an Infinite Bandwidth Interconnect, a Low Pin Count (LPC) bus, a memory bus, a Microchannel Architecture (MCA) bus, a Peripheral Component Interconnect (PCI) bus, a PCI-Express (PCI-X) bus, a Serial Advanced Technology Attachment (SATA) bus, a Video Electronics Standards Association Local (VLB) bus, or other suitable buses, or combinations of two or more of these. Where appropriate, bus 1210 may include one or more buses. Although specific buses are described and illustrated in embodiments of this application, any suitable bus or interconnect is contemplated herein.

[0189] Furthermore, in conjunction with the methods in the above embodiments, this application embodiment can provide a storage medium for implementation. This storage medium stores program instructions; when these program instructions are executed by a processor, they implement any of the methods in the above embodiments.

[0190] This application also provides a chip, which includes a processor and a communication interface. The communication interface and the processor are coupled. The processor is used to run programs or instructions to implement the various processes of the above method embodiments and achieve the same technical effect. To avoid repetition, it will not be described again here.

[0191] It should be understood that the chip mentioned in the embodiments of this application may also be referred to as a system-on-a-chip, system chip, chip system, or system-on-a-chip, etc.

[0192] This application provides a computer program product, which is stored in a storage medium and executed by at least one processor to implement the various processes of the above method embodiments and achieve the same technical effects. To avoid repetition, it will not be described again here.

[0193] It should be clarified that this application is not limited to the specific configurations and processes described above and shown in the figures. For the sake of brevity, detailed descriptions of known methods are omitted here. In the above embodiments, several specific steps are described and shown as examples. However, the method process of this application is not limited to the specific steps described and shown. Those skilled in the art can make various changes, modifications, and additions, or change the order of steps, after understanding the spirit of this application.

[0194] The functional modules shown in the above block diagram can be implemented as hardware, software, firmware, or a combination thereof. When implemented in hardware, they can be, for example, electronic circuits, application-specific integrated circuits (ASICs), appropriate firmware, plug-ins, function cards, etc. When implemented in software, the elements of this application are programs or code segments used to perform the required tasks. Programs or code segments can be stored on machine-readable media or transmitted over a transmission medium or communication link via data signals carried on a carrier wave. "Machine-readable media" can include any medium capable of storing or transmitting information. Examples of machine-readable media include electronic circuits, semiconductor memory devices, ROM, flash memory, erasable ROM (EROM), floppy disks, CD-ROMs, optical disks, hard disks, fiber optic media, radio frequency (RF) links, etc. Code segments can be downloaded via computer grids such as the Internet, intranets, etc.

[0195] It should also be noted that the exemplary embodiments mentioned in this application describe methods or systems based on a series of steps or apparatus. However, this application is not limited to the order of the above steps; that is, the steps can be performed in the order mentioned in the embodiments, or in a different order, or several steps can be performed simultaneously.

[0196] The aspects of this disclosure have been described above with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and program products according to embodiments of this disclosure. It should be understood that each block in the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to create a machine such that these instructions, executable via the processor of the computer or other programmable data processing apparatus, enable the implementation of the functions / actions specified in one or more blocks of the flowchart illustrations and / or block diagrams. Such a processor can be, but is not limited to, a general-purpose processor, a special-purpose processor, a special application processor, or a field-programmable logic circuit. It is also understood that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can also be implemented by special-purpose hardware performing the specified functions or actions, or can be implemented by a combination of special-purpose hardware and computer instructions.

[0197] The above are merely specific embodiments of this application. Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, modules, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here. It should be understood that the protection scope of this application is not limited thereto. Any person skilled in the art can easily conceive of various equivalent modifications or substitutions within the technical scope disclosed in this application, and these modifications or substitutions should all be covered within the protection scope of this application.

Claims

1. A data parsing method, characterized in that, Applied to Internet of Things (IoT) systems, the method includes: The system receives data packet frames sent by water resource monitoring equipment. The data packet frame includes a user data area, which includes address field data, user data field data, and control field data. The address field data is parsed to obtain the station address of the water resource monitoring equipment; Based on the function code in the control domain data and the station address, determine the target parsing method for the user data domain data; The user data domain data is parsed into formatted data according to the target parsing method described above; The step of parsing the address field data to obtain the station address of the water resource monitoring equipment includes: If the content of the first byte of the address field data does not match the third preset content, the last two bytes of the address field data are converted to obtain the station address. If the content of the first byte of the address field data matches the third preset content, the last four bytes of the address field data are converted according to the preset conversion method to obtain the station address.

2. The method according to claim 1, characterized in that, The data packet frame also includes a header area and a frame check area; Before parsing the address field data to obtain the station address of the water resource monitoring equipment, the method further includes: The message header area is parsed to obtain a valid result of the data message frame; If the valid result indicates that the data packet frame is valid, the data packet frame is verified according to the check code of the frame check area to obtain the verification result of the data packet frame. The step of parsing the address field data to obtain the station address of the water resource monitoring equipment includes: If the verification result indicates that the data packet frame passes the verification, the address field data is parsed to obtain the station address of the water resources monitoring equipment.

3. The method according to claim 2, characterized in that, The data message frame also includes an end character area; The step of parsing the message header area to obtain a valid result of the data message frame includes: The message header area is parsed to obtain the byte content of the first byte, the second byte, and the third byte of the message header area; Obtain the length of the first byte in the data packet frame excluding the header area, and the total byte length of the user data area, the frame check area, and the end character area; If the byte content of the first byte in the header area matches the first preset content, and the byte content of the third byte matches the second preset content, and the length of the first byte is equal to the total byte length, the valid result is determined as the first result, and the first result indicates that the data packet frame is valid. If the first condition is met, the valid result is determined as the second result, and the second result indicates that the data packet frame is invalid; The first condition includes at least one of the following: The byte content of the first byte does not match the first preset content; The content of the third byte does not match the second preset content; The length of the first byte is not equal to the total byte length.

4. The method according to claim 3, characterized in that, The byte content of the second byte includes the data length of each data area in the data packet frame; The step of verifying the data packet frame based on the checksum of the frame check area to obtain the verification result of the data packet frame includes: Based on the data length of each data area in the data packet frame, the checksum of the frame check area and the byte content of the user data area are obtained; The byte content of the user data area is verified and the calculation result is obtained. If the calculation result matches the check code, the check result is determined as the third result, and the third result indicates that the data packet frame has passed the check. If the calculation result does not match the check code, the check result is determined as the fourth result, which indicates that the data packet frame verification fails.

5. The method according to claim 1, characterized in that, The step of determining the target parsing method for the user data domain data based on the function code in the control domain data and the station address includes: If the function code matches the fourth preset content stored in the database, the target parsing method corresponding to the function code is retrieved from the database; If the function code does not match the fourth preset content stored in the database, the target parsing method corresponding to the function code and the station address is obtained.

6. A data parsing device, characterized in that, The device, used in an Internet of Things (IoT) system, includes: The receiving module is used to receive data message frames sent by water resource monitoring equipment. The data message frame includes a user data area, which includes address field data, user data field data, and control field data. The first parsing module is used to parse the address field data to obtain the station address of the water resource monitoring equipment; The determination module is used to determine the target parsing method of the user data domain data based on the function code in the control domain data and the station address; The second parsing module is used to parse the user data domain data into formatted data according to the target parsing method; The first parsing module is specifically used for: If the content of the first byte of the address field data does not match the third preset content, the last two bytes of the address field data are converted to obtain the station address. If the content of the first byte of the address field data matches the third preset content, the last four bytes of the address field data are converted according to the preset conversion method to obtain the station address.

7. An electronic device, characterized in that, The device includes: a processor and a memory storing computer program instructions; When the processor executes the computer program instructions, it implements the data parsing method as described in any one of claims 1-5.

8. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer program instructions, which, when executed by a processor, implement the data parsing method as described in any one of claims 1-5.

9. A computer program product, characterized in that, When the instructions in the computer program product are executed by the processor of the electronic device, the electronic device performs the data parsing method as described in any one of claims 1-5.

Images