A method for sharing water network project dispatching and operation monitoring data

Abstract

The present invention discloses a method for sharing water network engineering scheduling and operation monitoring data, which is applied to the technical field of water conservancy communication protocol, and includes the following steps: defining MNZ matrix protocol, developing MNZ matrix protocol system; matching Internet of Things smart devices and sending MNZ matrix protocol to Internet of Things smart devices; collecting water network engineering scheduling and operation monitoring data, generating protocol data according to MNZ matrix protocol; transmitting protocol data to remote control system or database; parsing protocol data according to MNZ matrix protocol rules, and obtaining water network engineering scheduling and operation monitoring data. The MNZ matrix protocol of the present invention can be directly stored in the library, parsed when called, parsed when changed, dynamically defined, and quickly adapted, and can customize protocol content, adapt to equipment, self-match existing protocols, realize free sharing of communication between devices, enhance the efficiency of data collection, transmission, and parsing, reduce the difficulty of development and debugging of dependent equipment, and reduce the risk of operation and maintenance.

Description

Technical Field

[0001] The present invention relates to the technical field of water conservancy communication protocols, and more specifically to a method for sharing water network project dispatching and operation monitoring data. Background Art

[0002] The dispatching automation control system of the water conservancy cascade pump station is composed of numerous monitoring devices, control devices, PLCs and host computers. The interaction between the devices depends on numerous drivers and protocols. Therefore, the integrity, self-recovery and self-verification of the data link are very important. The existing cascade pump station control relies more on the power IEC104 protocol, industrial Modbus communication and OPC communication protocol for data communication and interaction. The power or industrial communication protocol developed earlier and has more iterative versions. On the one hand, it is necessary to adapt to the existing equipment and industrial control systems; on the other hand, it is also necessary to adapt to new Internet of Things devices, and the debugging difficulty and adaptability are poor. If the monitoring equipment wants to communicate with the PLC and host computer, it must rely on the existing mature protocols. If you want to customize unique functions, you must use the underlying language for development, which is limited by the protocol itself, development technology, fixed debugging mode, open class library, component library encapsulation and other factors.

[0003] The characteristics of cascade pump station monitoring data make the data full of variables and can no longer be transmitted using fixed communication protocols. It is necessary to modify the data transmission content synchronously in combination with data status and behavior events to adapt to real-time mutations. In order to accurately measure the data, it is necessary to deploy the same sensors in a certain area, perform fusion calculations, and output stable monitoring data. This method can only be converted through the host computer. Therefore, how to achieve accurate transmission of cascade pump station monitoring data is an urgent problem that technicians in this field need to solve. Summary of the invention

[0004] In view of this, the present invention provides a method for sharing water network project scheduling and operation monitoring data, which can achieve seamless connection between devices, between devices and systems, and between systems, and realize protocol-based data calculation, data sharing, data transmission and data broadcasting.

[0005] In order to achieve the above object, the present invention provides the following technical solutions:

[0006] A method for sharing water network project scheduling and operation monitoring data, comprising the following steps:

[0007] S1. Define the MNZ matrix protocol and develop the MNZ matrix protocol system;

[0008] S2, match the IoT smart device and send the MNZ matrix protocol to the IoT smart device;

[0009] S3, collect water network project dispatching and operation monitoring data, and generate protocol data according to the MNZ matrix protocol;

[0010] S4, transmitting the protocol data to a remote control system or database;

[0011] S5. Parse the protocol data according to the MNZ matrix protocol rules to obtain the water network project scheduling and operation monitoring data.

[0012] Optionally, the MNZ matrix protocol includes: a protocol header, a protocol group, and a protocol tail;

[0013] The protocol header marks the start of transmission; the protocol group is divided into three dimensions: attribute M dimension, data N dimension, and protocol and security Z dimension; the protocol tail marks the end of transmission.

[0014] Optionally, the MNZ matrix protocol also includes a security code, which is hexadecimal data generated by using a user and password.

[0015] Optionally, the M dimension is an attribute dimension that marks the attributes of the data and defines the type of device, location information, data type, number of data bits, data storage, data measurement size, data status, data threshold, data alarm, event status, scheduling status, and extended information;

[0016] The N dimension is the specific data embodiment of the M dimension. It forwards and controls the protocol and determines the content and format requirements of the data to be transmitted.

[0017] The Z dimension defines the metadata items of the M dimension, including: security protocol, priority, optimization strategy, data metering size, data status, data threshold, and security policy.

[0018] Optionally, S2 specifically includes: matching the IoT smart device, determining whether the device supports the MNZ matrix protocol, and canceling the matching if it does not support it; if it does support it, the IoT smart device directly connects to the MNZ matrix protocol system, generates a unique identifier for marking after establishing the connection, and the generated unique identifier serves as the basis for encoding and decoding the MNZ matrix protocol.

[0019] Optionally, multiple IoT smart devices are interconnected, and based on the MNZ matrix protocol, the monitoring data is placed in a shared area. The monitoring data in the shared area is independently retrieved to participate in the calculation, or the monitoring data is integrated and calculated in the shared area and output as a unified output result; the monitoring data sharing method between IoT smart devices is one of a star topology or a ring topology.

[0020] Optionally, when S2 matches an IoT smart device, the MNZ matrix protocol is verified, specifically: when matching an IoT smart device, the IoT smart device is parsed, a protocol body is generated, the test data corresponding to the MNZ matrix protocol is sent to the corresponding IoT smart device, and feedback data is received. If the feedback data is consistent with the data in the standard definition library, the current protocol body is recognized as successful; after the IoT smart device is successfully matched, the current status is recorded, and the protocol body is repeatedly recognized. If all protocol bodies are successfully recognized, it is successful. If unsuccessful, manual correction is performed.

[0021] It can be seen from the above technical solution that, compared with the prior art, the present invention discloses a method for sharing water network engineering scheduling and operation monitoring data, which has the following beneficial effects: it can be directly stored in the warehouse, parsed when called, parsed when changed, dynamically defined, and quickly adapted, and can customize the protocol content, adapt to the equipment, and self-match the existing protocol to achieve free sharing of communication between devices, enhance the efficiency of data collection, transmission, and parsing, reduce the difficulty of development and debugging that depends on the equipment, and reduce the risk of operation and maintenance; it can directly transmit binary in the optical fiber through dimensional calculation, without parsing support, and the parsed data has no meaning; it solves the problem of large data storage, does not need to store each indicator, but stores it as an object, and solves the problem of multi-dimensional data storage; reduces the amount of data storage, saves storage space, and is conducive to long-term data preservation. BRIEF DESCRIPTION OF THE DRAWINGS

[0022] In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on the provided drawings without paying creative work.

[0023] Figure 1 is a flow chart of the data sharing method of the present invention;

[0024] Figure 2 It is a star topology diagram of the present invention;

[0025] Figure 3 This is a ring topology diagram of the present invention. DETAILED DESCRIPTION

[0026] The following will be combined with the drawings in the embodiments of the present invention to clearly and completely describe the technical solutions in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0027] The embodiment of the present invention discloses a method for sharing water network project scheduling and operation monitoring data. Figure 1 As shown, the following steps are included:

[0028] S1. Define the MNZ matrix protocol and develop the MNZ matrix protocol system;

[0029] S2, match the IoT smart device and send the MNZ matrix protocol to the IoT smart device;

[0030] S3, collect water network project dispatching and operation monitoring data, and generate protocol data according to the MNZ matrix protocol;

[0031] S4, transmitting the protocol data to a remote control system or database;

[0032] S5. Parse the protocol data according to the MNZ matrix protocol rules to obtain the water network project scheduling and operation monitoring data.

[0033] Furthermore, the MNZ matrix protocol includes: a protocol header, a protocol group, and a protocol tail;

[0034] The protocol header marks the start of transmission; the protocol group is divided into three dimensions: attribute M dimension, data N dimension, and protocol and security Z dimension; the protocol tail marks the end of transmission.

[0035] Specifically, the entire MNZ matrix protocol is wrapped in a "{}", and the four parts are combined with "[]". The three dimensions in the protocol body are respectively used as a whole with "()", and the dimensions are separated by "," and the dimensions are separated by " / ". The protocol format corresponds to the protocol content one by one:

[0036] The MNZ matrix protocol is defined directly using registers of sub-dimensions

[0037] {[protocol

[0038] Header][(31M / 33M / 34M / 35M / 36M / 37M / 38M / 39M / ),(31N / 33N / 34N / 35N / 36N / 37N / ),(31Z / 33Z / 34Z / 35Z / 31Z02TY / 31Z02TY01 / 38Z / 39Z / )][Security Code][Protocol End]}

[0039] The content of the protocol is the feedback to the protocol header:

[0040] {[S7T7H][(01 / 03 / 04 / 01 / 365403 / 12 / 01 / 01 / ),(01 / 03 / 04 / 01 / 360203 / 12 / ),(01 / 02 / 04 / 01 / 01 / 01 / 38 / 06 / )][1ABD][S7P7E]}

[0041] Agreement feedback: Feedback based on the agreement content and in accordance with the format requirements:

[0042] {[S7T7H][(31M / 36M / 39M / ),(SWJ1021X / 332506 / 04 / 2564 / )][1ABD][S7P7E]}.

[0043] Among them, SWJ1021X is the water level meter number, 332546 is marked as the collected value, 04 is the collected value that needs to be shifted four places to the left, the actual value is 33.2546, and the collection timestamp is 2146.

[0044] The MNZ matrix protocol is a communication protocol between different devices used in the water network engineering scheduling and operation monitoring data sharing method of the present invention. It can be expanded based on any dimension to form a sub-dimension, and the sub-dimension can be expanded to a sub-sub-dimension. There is no restriction on the definition method and it can be expanded without limit to meet the requirements of data transmission in multiple scenarios of water conservancy industry data. The MNZ matrix protocol can adapt to buses, various protocols, and various devices, intelligently adapt access devices on the MNZ platform, provide wizard-style configuration and establish contact channels. MNZ can perform device attribute marking and modular management, and the data transmission protocol will be simpler, more reliable, more stable and more efficient. MNZ supports more than three scheduling modes, namely subscription mode, response mode and read-write mode. Data transmission adopts Subscription mode, when scheduling control is required, interaction is carried out through the response mode, and the read-write mode is applicable to configuration management; MNZ will support direct writing into chips, gateway devices, and information platforms, and overall management of protocols can be carried out in all links; MNZ can be directly edited into a driver and built into the existing PLC control program driver library to achieve communication with PLC and other devices, which can not only give play to the advantages of PLC, but also connect to the water conservancy Internet of Things devices of the MNZ matrix protocol; MNZ supports platform to device, realizes fiber-to-device connection, reduces the number of intermediate links and unreliability factors; MNZ supports dynamic data and static data, and only performs dynamic protocol analysis during protocol analysis. When calculating based on static indicators, the static indicators of related registers are analyzed to improve calculation efficiency. Capability; MNZ can perform data scheduling, support automatic allocation, manual designation, emergency transmission and other modes (single-channel and multi-channel transmission {balanced transmission}, signal transmission and power transmission merged, etc.); based on the MNZ standard communication power supply interface, support device to device, build a protocol-level self-loop / closed-loop network, and realize device-level data sharing, data calculation, and data forwarding {the same device sensors in the same area are interconnected, and as a whole group of devices output a monitoring value and monitoring status}; based on the calculation of data during the transmission process of MNZ, direct operation between registers is realized, and data trends can be discovered faster (the implementation method can be chips, protocols themselves, and remote platforms); MNZ defines the integrity of data transmission protocols, and data transmission The data is transmitted as a whole based on the protocol definition, without splitting; when data is transmitted based on MNZ, it relies on 8421BCD code instead of binary data, and does not need to be packaged or unpacked; MNZ data transmission can support optical fiber for underlying communication, and can also communicate with Internet-related communication protocols to realize device Internet of Things; MNZ is a standard protocol that defines relevant standards, which can reduce the number of point tables in the automation system, eliminate the trouble of data management, and can lighten the SCADA system, connect to PLC, and connect to the data management platform; based on the storage function of MNZ equipment, the recent historical data stored in the equipment can be retrieved through the definition of the Z dimension of the protocol; based on MNZ data, it can directly enter the database and perform matrix or reduced dimensionality storage;Based on MNZ combined with the scheduling mode, the data can be qualitatively calibrated through the customizable output of Z dimension; MNZ can adapt to the existing 485 / 232 protocol, the IEC protocol and Modbus protocol of power, and various PLCs, and has universality; the protocol for MNZ equipment access can adapt to power supply and communication, and make comprehensive use of the number of cables; the MNZ protocol has the function of communication link test, and can find the effective link status through link test; MNZ protocol data can directly store characteristic indicators in the library without parsing before storage, which improves storage efficiency; MNZ protocol supports time verification and synchronization function, which can synchronize the verification of equipment and system time, while ensuring time consistency, omitting the time bit transmission, sending time events when the time is inconsistent, and uniformly matching; it can be calculated based on registers, directly applied to the configuration system and front-end display, and can be directly stored in the library, parsed when used, parsed when changed, dynamically defined, and quickly adapted. ;

[0045] Furthermore, the MNZ matrix protocol also includes a security code, which is a hexadecimal data generated by using a user and password. In a specific environment, the protocol header and protocol tail can be defined by yourself, depending on the function of the protocol. For example, in a pump station, the protocol header can start with STDLBZ and end with SPDLBZ, which is used for internal protocols, and the security code is optional.

[0046] The MNZ matrix protocol cannot be unpacked and is transmitted as a whole. The definition, scheduling, parsing, and storage of the detailed MNZ matrix protocol are clearly marked in the development MNZ matrix system.

[0047] Furthermore, the M dimension is the attribute dimension, which marks the attributes of the data and defines the type of equipment, location information, data type, number of data bits, data storage, data measurement size, data status, data threshold, data alarm, event status, scheduling status, and extended information;

[0048] The N dimension is the specific data embodiment of the M dimension. It forwards and controls the protocol and determines the content and format requirements of the data to be transmitted.

[0049] The Z dimension defines the metadata items of the M dimension, including: security protocol, priority, optimization strategy, data metering size, data status, data threshold, and security policy.

[0050] Specifically: M-dimensional attributes are separated by “ / ”, and the number and position of “ / ” can be calculated by a function, and the position can be quickly located by shifting.

[0051] The data of M-dimensional attributes are stored in different registers. The register identifiers are marked with different symbols. The data in the registers are kept uniform as much as possible and marked starting with 31M, as shown in Table 1:

[0052] Table 1

[0053]

[0054]

[0055] The register value is the actual collected data and calculation results in the N dimension, which are distributed in the Z dimension.

[0056] The N dimension is the specific data embodiment of M. It relies on scheduling principles and rules to forward and control the protocol. The scheduling strategy for data transmission ultimately determines the content and format requirements of the data to be transmitted. The data is stored in different registers. The register identifiers are marked with different symbols. The data in the registers are kept as unified as possible and marked starting with 31N, as shown in Table 2:

[0057] Table 2

[0058]

[0059] Monitoring and operation of N-dimensional data, marking device type as

[01] , location information as [front 01], data type as [integer 01], number of data bits as [3], data storage as

[12754] , data measurement size as

[01] , data status as

[00] , data threshold as [1], data alarm as [0], event status as [0], scheduling status as [0], and other information.

[0060] The Z dimension is an extended dimension or metadata dimension, which defines the metadata items of the M-dimensional attributes, including security protocols, priorities, optimization strategies, sizes, states, types, thresholds, security strategies, and other information. The Z attributes are stored in different registers, and the register identifiers are marked with different symbols. The data in the registers are kept as unified as possible, and are marked with 31Z. When the extended information is needed, the registers are automatically assigned values, as shown in Table 3:

[0061] Table 3

[0062] Serial number Register Identification Register Description Register Address Register Value 1 31Z Device Type 31Z01 01 2 32Z Location Information 31Z02 01 3 33Z Data Types 31Z03 01 4 34Z Number of data bits 31Z04 03 5 35Z Data storage 31Z05 12754 6 36Z Data measurement size 31Z06 01 7 37Z Data Status 31Z07 00 8 38Z Data Threshold 31Z08 1 9 39Z Data Alert 31Z09 0 10 40Z Event Status 31Z10 0 11 41Z Protocol Type 31Z11 00 12 42Z Shift method 31Z12 01 13 43Z Number of shifts 31Z13 04 14 44Z Timestamp 31Z14 102634 15 45Z Priority 31Z15 01 16 46Z Scheduling strategy 31Z16 01 17 48Z Extended Information 31Z18 00

[0063] Taking the device type as an example, the calling relationship of the dimension is explained. The register 31M in the M dimension is the device type and the associated register 31Z. The corresponding register identifier 31Z is found in the Z dimension "Z dimension-1". The register address 31Z01 is associated with the device type 31Z02TY in "Z dimension-2". The register description is matched in "Z dimension-3" through the register identifier, and the register address is fed back to the 31M dimension to complete the value acquisition. Among them, the time status register address 0 is marked as no event status, and 1 is marked as event status; the protocol type register address 0 is marked as MNZ protocol itself, 1 is marked as TCP protocol, 2 is marked as Modbus protocol, 3 is marked as OPC protocol, and 4 is marked as IEC 104 protocol; the shift mode register address 00 is marked as no shift, 01 is marked as left shift, and 02 is marked as right shift; the shift bit register address is used to confirm the shift bit based on the shift mode; the timestamp register address is the timestamp concept, for example, 102634 means 10:26:34, if it is 2 digits, it is the interval time; the priority register address is whether the transmission is given priority, 00 is marked as transmission according to system rules, 01 is marked as priority, and 02 is downgraded by one level; in the scheduling strategy register address, 00 is marked as no scheduling record, and 01 is marked as a scheduling strategy.

[0064] The sub-dimension tags of device type and address 31Z01 are shown in Table 4:

[0065] Table 4

[0066] Serial number Register Identification Register Description Register Address Register value 1 31Z01 Equipment No. 31Z01CO SWJ1021X 2 31Z02 Device Type 31Z02TY Water level gauge 3 31Z03 Factory time 31Z03TY 20220110 4 31Z04 Manufacturer 31Z04TY Tsinghua Tongfang 5 31Z05 Card Type 31Z05TY integrated circuit 6 31Z06 Power supply 31Z06TY 31Z06ZDC 7 31Z07 Chip Type 31Z07TY 28nm 8 31Z08 Extended Information 31Z08TY

[0067] The sub-dimension tags of the device type and register address 31Z02TY are shown in Table 5:

[0068] Table 5

[0069] Serial number Register Identification Register Description Register value 1 31Z02TY01 Water level gauge 01 2 31Z02TY02 Flow Meter 02 3 31Z02TY03 Opening meter 03 4 31Z02TY04 Osmometer 04 5 31Z02TY05 Displacement Meter 05 6 31Z02TY06 Thermometer 06 7 31Z02TY07 Extended Information 07 8 31Z02TY08 Extended Information 08 9 31Z02TY09 Extended Information 09 10 31Z02TY10 10

[0070] Furthermore, S2 is specifically: matching the IoT smart device, determining whether the device supports the MNZ matrix protocol, and canceling the matching if it does not support it; if it does support it, the IoT smart device directly connects to the MNZ matrix protocol system, and generates a unique identifier for marking after the connection is established. The generated unique identifier serves as the basis for encoding and decoding the MNZ matrix protocol.

[0071] Furthermore, multiple IoT smart devices are interconnected, and based on the MNZ matrix protocol, monitoring data is placed in a shared area, and the monitoring data in the shared area is independently retrieved for operation or the monitoring data is integrated and operated in the shared area, and output as a unified output result; the monitoring data sharing method between IoT smart devices is one of the star topology or ring topology. The star topology is as follows: Figure 2 As shown, the ring topology is as follows Figure 3 shown.

[0072] Combine IoT smart devices in the area according to different structures, specify the main device or shared content to prevent sharing conflicts. For the shared data calculated as a single value, the shared value can be directly displayed in the register. For devices that share at the same time, address pointers are required to different registers.

[0073] The data sharing strategy structure is divided into: single-value sharing structure and multi-value sharing structure. The single-value sharing structure is shown in Table 6, and the multi-value sharing structure is shown in Table 7:

[0074] Table 6

[0075]

[0076]

[0077] Table 7

[0078] Serial number Device Type Device location Sharing method Register Address Shared Cache Number of data bits 1 31Z 32Z 02 49Z01 49Z09SH 34Z

[0079] The pointer types of the shared cache are shown in Table 8:

[0080] Table 8

[0081] Serial number Shared Cache Device Code Register Address Register Value Number of data bits 1 49Z09SH SWJ1021X 36N 36.22 34Z 2 49Z09SH SWJ1022X 36N 36.23 34Z 3 49Z09SH SWJ1023X 36N 36.45 34Z 4 49Z09SH SWJ1024X 36N 25.98 34Z 5 49Z09SH SWJ1025X 36N 25.43 34Z

[0082] The MNZ matrix protocol supports two or more scheduling modes, namely subscription mode, response mode and read-write mode. The mechanisms and processes corresponding to the three modes are different. Subscription mode: A mode in which the protocol system subscribes to data from the device. The device, based on the subscription requirements, periodically feeds back data to the protocol system for use by various services. The subscription mechanism must include the subscribed message header, message body, security code, and message tail. The feedback data also includes the message header, message body, security code, and message tail. The message body is the core, and the content is different in subscription and feedback. Response mode: The response mode also requires definition of the response requirements, including the number of responses, response content, standard definition, and other aspects. The subscription, response setting and verification process is shown in Table 9:

[0083] Table 9

[0084]

[0085]

[0086] Specifically, in the scheduling strategy register value, 01 is marked as a subscription mechanism, 02 is marked as a response mechanism, and 03 is marked as a read-write mechanism. The specific process of subscription, response setting and verification is as follows: After the MNZ matrix protocol system self-checks, it determines whether there is a problem. If there is, it sends an alarm message and notifies the administrator for maintenance. If not, it selects the scheduling mode; the scheduling mode is divided into subscription and response modes. In the subscription mode, the subscription strategy is compiled, the water conservancy Internet of Things devices are screened, the network mode is adapted, the device is selected and the subscription strategy is issued. The IoT device ends after the subscription strategy is successfully executed. In the response mode, the response strategy is compiled, the water conservancy control equipment is screened, the network mode is adapted, the device is selected and the response strategy is issued, and a mapping relationship is established. After the water conservancy equipment successfully executes the response strategy, the message content is displayed and compared with the response strategy, and the MNZ matrix protocol system is requested to self-check at the same time.

[0087] Furthermore, independent dimensions are calculated and stored using mathematical functions, and the decimal system is uniformly converted into four-bit binary, and the optical fiber path is directly connected to the protocol system for database storage. The protocol system can combine dimensions, convert them into hexadecimal data according to the base conversion, and the result of the uniform conversion of the three dimensions M, N, and Z is an array, such as: KEYM33N33Z34, VALUE[0F19, 3EFD, 9FA111BC]. The storage mode is key-value storage, which can save storage space and improve interpretation efficiency. In the MNZ matrix dimension, there are many defined data attributes, and the algorithms and models will be built into part of the protocol. When the data is actually running, only the monitoring data and control information may change, and the rest will not change. Based on this type of data, only the changed data on the specified dimension needs to be stored. For example: KEY N34, VALUEN[0F11], actual valid data. If this type of data is to be stored, it is necessary to perform protocol integrity, rationality, accuracy, compliance and other verifications before storage, and the protocol and encoding to which it belongs must be marked. Based on the protocol, classified data can be stored. For normal data, only the storage after the change is concerned. For abnormal data, it needs to enter the abnormal database. The data entering the abnormal database needs to pass the logic check, process check, and accuracy check to analyze the cause of the abnormal data. At the same time, it can be connected with the management system to start the external program. After the protocol verification, if the content of this data is marked in the protocol as consistent with the content of the previous data, it does not need to be stored or parsed. The data of the previous protocol data can be regarded as the content of this protocol, and so on, until the protocol changes or reaches the threshold condition (24H, or 48H, or 96H).

[0088] Dimensional storage can directly transmit binary (more accurately, 8421BCD code) in optical fibers through dimensional calculations. Without parsing support, the parsed data will be meaningless. It can solve the problem of large data storage. It does not need to store each indicator, but stores it as an object to solve the problem of multi-dimensional data storage. It reduces the amount of data stored, saves storage space, is conducive to long-term data preservation, and provides data support for big data storage and management.

[0089] Furthermore, when S2 matches the IoT smart device, the MNZ matrix protocol is verified, specifically: when matching the IoT smart device, the IoT smart device is parsed, a protocol body is generated, the test data corresponding to the MNZ matrix protocol is sent to the corresponding IoT smart device, and feedback data is received. If the feedback data is consistent with the data in the standard definition library, the current protocol body is recognized as successful; after the IoT smart device is successfully matched, the current status is recorded, and the protocol body is repeatedly recognized. If all protocol bodies are successfully recognized, it is successful. If unsuccessful, manual correction is performed.

[0090] Specifically, the subscribed message format is: {[S7T7H][(31M / 34M / 36M),(36N),(59Z)][1ABD][S7T7E]}, which obtains 36M data information from the device marked as 31M, shifts 34M bits to the left, and stores it in the 36N register at a time interval of 59Z. Subscribed message content: {[S7T7H][(SWJ1021X / 4),(),(5)][1ABD][S7T7E]}, which defines the message header, tail and security code, and feedbacks the water level data of the number SWJ1021X.

[0091] The subscription mechanism feedback message is: {[S7T7H][(31M),(36N),(60Z,37Z)][S7T7E]}. The message feedback defines that the data is fed back from the 31M device at an interval of 60Z and stored in 36N, and 37Z marks the data status. If it is in a highly isolated environment, the security code can be omitted. The subscription feedback content is: {[S7T7H][(SWJ1021X),(240526),(30 / 0)][1ABD]}. The feedback content defines the water level meter numbered SWJ1021X, the measured data is 24.0526 (using the definition of 34M, shifted 4 bits to the left), the time is 30S interval, and the data status is normal.

[0092] Perform protocol-level data verification, including data status, communication status, event status, and other types of status verification to ensure data accuracy, integrity, and processing strategies.

[0093] Data status verification: Sending data status verification, based on the data status expression of the protocol, after coordinated verification of the measured data with the threshold, alarm value and compliance verification, feedback is given on whether the data is in a valid state. The data can only be received when it is valid. If the data status is invalid, there is no need to transmit it; receiving data status verification, based on the protocol-level data, performs data status verification to mark whether there are any abnormalities, non-compliance or loss after transmission. Verification at the protocol level can ensure the validity and integrity of the data.

[0094] Communication status verification: The communication status refers to the data link (logically defined) between the sender and the receiver, including unidirectional and bidirectional links, transmission and control links, sending and receiving links, etc. The communication and status corresponding to each type of link are different, and the data status is also different under different link communication status. For example, if the communication link is abnormal but the data status is normal, it is event data and needs to be resent, otherwise the data is discarded or the cause of the problem is retrieved.

[0095] Event status check: An event is an operation or status of data or protocol. An event can be triggered by data. When the data is greater than the threshold, the data anomaly is directly fed back and defined as an event. The abnormal data can be investigated or destroyed in combination with the scheduling principle. An event can be triggered by data change. When the data changes from the last time and the range exceeds the specified threshold, the changed data is marked as an event and transmitted directly. When the receiving end receives the data, it first determines the event status. If it is changed data, it is parsed, applied and stored. Otherwise, it is not parsed and the last parsed data is used.

[0096] Other types of exceptions can be managed by defining events and their impact.

[0097] Furthermore, each dimension in the MNZ matrix requires support from various attribute indicators. One is the formatted and defined dictionary information, and the other needs to be manually defined based on business scenarios. When defining, the accuracy, uniqueness and irreplaceability of the data must be guaranteed.

[0098] The various embodiments in this specification are described in a progressive manner, and each embodiment focuses on the differences from other embodiments. The same or similar parts between the various embodiments can be referenced to each other.

[0099] The above description of the disclosed embodiments enables one skilled in the art to implement or use the present invention. Various modifications to these embodiments will be apparent to one skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the present invention. Therefore, the present invention will not be limited to the embodiments shown herein, but rather to the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A method for sharing water network project scheduling and operation monitoring data, characterized in that: The following steps are involved: S1. Define the MNZ matrix protocol and develop the MNZ matrix protocol system; S2, match the IoT smart device and send the MNZ matrix protocol to the IoT smart device; S3, collect water network project dispatching and operation monitoring data, and generate protocol data according to the MNZ matrix protocol; S4, transmitting the protocol data to a remote control system or database; S5. Parse the protocol data according to the MNZ matrix protocol rules to obtain the water network project dispatching and operation monitoring data; The MNZ matrix protocol includes: protocol header, protocol group, and protocol tail; The protocol header is a marker for the start of transmission; the protocol group is divided into three dimensions: attribute M dimension, data N dimension, and protocol and security Z dimension; the protocol tail is a marker for the end of transmission; M dimension is the attribute dimension, which marks the attributes of the data and defines the type of equipment, location information, data type, number of data bits, data storage, data measurement size, data status, data threshold, data alarm, event status, scheduling status, and extended information; The N dimension is the specific data embodiment of the M dimension. It forwards and controls the protocol and determines the content and format requirements of the data to be transmitted. The Z dimension defines the metadata items of the M dimension, including: security protocol, priority, optimization strategy, data metering size, data status, data threshold, and security policy.

2. A method for sharing water network engineering scheduling and operation monitoring data according to claim 1, characterized in that: The MNZ matrix protocol also includes a security code, which is hexadecimal data generated by using a user and password.

3. A method for sharing water network engineering scheduling and operation monitoring data according to claim 1, characterized in that: S2 is specifically: matching the IoT smart device, determining whether the device supports the MNZ matrix protocol, and canceling the matching if it does not support it. If it does support it, the IoT smart device directly connects to the MNZ matrix protocol system, generates a unique identifier for marking after the connection is established, and the generated unique identifier serves as the basis for encoding and decoding the MNZ matrix protocol.

4. A method for sharing water network engineering scheduling and operation monitoring data according to claim 1, characterized in that: Multiple IoT smart devices are interconnected, and based on the MNZ matrix protocol, the monitoring data is placed in a shared area. The monitoring data in the shared area is independently retrieved to participate in the calculation, or the monitoring data is integrated and calculated in the shared area and output as a unified output result; the monitoring data sharing method between IoT smart devices is one of the star topology or ring topology.

5. A method for sharing water network engineering scheduling and operation monitoring data according to claim 1, characterized in that: When S2 matches the IoT smart device, the MNZ matrix protocol is verified, specifically: when matching the IoT smart device, the IoT smart device is parsed, a protocol body is generated, the test data corresponding to the MNZ matrix protocol is sent to the corresponding IoT smart device, and feedback data is received. If the feedback data is consistent with the data in the standard definition library, the current protocol body is recognized as successful; after the IoT smart device is successfully matched, the current status is recorded, and the protocol body is repeatedly recognized. If all protocol bodies are successfully recognized, it is successful. If unsuccessful, manual correction is performed.

Images