CN117499380A - Custom protocol data acquisition method - Google Patents
Custom protocol data acquisition method Download PDFInfo
- Publication number
- CN117499380A CN117499380A CN202311582856.XA CN202311582856A CN117499380A CN 117499380 A CN117499380 A CN 117499380A CN 202311582856 A CN202311582856 A CN 202311582856A CN 117499380 A CN117499380 A CN 117499380A
- Authority
- CN
- China
- Prior art keywords
- message
- protocol
- module
- data
- fields
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 238000000034 method Methods 0.000 title claims abstract description 24
- 230000004044 response Effects 0.000 claims description 26
- 230000014509 gene expression Effects 0.000 claims description 14
- 238000004891 communication Methods 0.000 claims description 10
- 238000006243 chemical reaction Methods 0.000 claims description 8
- 230000008859 change Effects 0.000 claims description 3
- 230000003068 static effect Effects 0.000 claims description 3
- 238000010586 diagram Methods 0.000 description 14
- 230000008569 process Effects 0.000 description 4
- 230000005540 biological transmission Effects 0.000 description 3
- 238000012795 verification Methods 0.000 description 3
- 238000004458 analytical method Methods 0.000 description 2
- 238000011161 development Methods 0.000 description 2
- 238000007667 floating Methods 0.000 description 2
- 230000004075 alteration Effects 0.000 description 1
- 238000003491 array Methods 0.000 description 1
- 230000009286 beneficial effect Effects 0.000 description 1
- 238000004364 calculation method Methods 0.000 description 1
- 238000004140 cleaning Methods 0.000 description 1
- 238000013480 data collection Methods 0.000 description 1
- 238000007418 data mining Methods 0.000 description 1
- 238000013461 design Methods 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 238000007429 general method Methods 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 238000012545 processing Methods 0.000 description 1
- 238000005316 response function Methods 0.000 description 1
- 238000006467 substitution reaction Methods 0.000 description 1
- 238000012360 testing method Methods 0.000 description 1
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/03—Protocol definition or specification
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/66—Arrangements for connecting between networks having differing types of switching systems, e.g. gateways
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/08—Protocols for interworking; Protocol conversion
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/22—Parsing or analysis of headers
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
- Y02P—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN THE PRODUCTION OR PROCESSING OF GOODS
- Y02P90/00—Enabling technologies with a potential contribution to greenhouse gas [GHG] emissions mitigation
- Y02P90/02—Total factory control, e.g. smart factories, flexible manufacturing systems [FMS] or integrated manufacturing systems [IMS]
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Security & Cryptography (AREA)
- Computer And Data Communications (AREA)
Abstract
The invention discloses a custom protocol data acquisition method, which comprises the following steps: A. based on the acquisition function of the NLink edge gateway, the NLink edge gateway is enabled to have the configurable and dynamically expandable self-defined protocol acquisition capacity; B. adding a protocol in a custom protocol page, and filling a CARJIMI protocol name; C. newly adding a message under the CARJIMI protocol, filling out the name of an OutVoltage message, automatically loading fixed head and tail fields of the protocol to which the message belongs, and not modifying the fields; D. synchronizing the json configuration file to the end module, and analyzing the configuration file by the end module. The invention enables the edge gateway to support dynamic expansion protocol by configuring the function of the custom protocol, collects data of more kinds of equipment, the user OT system integrates new equipment, the user only needs to add the protocol on the edge gateway according to the format defined by the protocol, and the collected data is reported to the OT system through unified Http and MQTT protocols.
Description
Technical Field
The invention relates to the technical field of computers and the field of industrial controllers, and discloses a method for acquiring data of a custom protocol. When integrating new equipment such as fire-fighting equipment, vehicle-mounted equipment, AGV (automatic guided vehicle) equipment and the like and adopting equipment manufacturers' own communication protocols, a user can collect data of a new protocol in an edge gateway by only adding the new protocol on the edge gateway according to a format defined by the protocol, and report the collected data to the OT system through unified Http and MQTT protocols, thereby reducing the cost of independently developing each protocol or accessing the new hardware cost of the edge gateway, and unifying the analysis mode of the protocol and the reported format.
Background
Along with the continuous development of industry 4.0, the requirements of industrial control data acquisition, edge calculation, centralized cleaning, data mining and intelligent regulation are more and more vigorous, the equipment required to be acquired by an OT system is more and more diversified, and the communication protocol used by the equipment is also complex. An edge gateway is often only capable of handling a few protocols which are relatively general or widely used, which results in that a part of protocols need to be developed separately, development cost is increased, a part of protocols need to be added with edge gateways separately, hardware cost is increased, and therefore, the acquisition cost needs to be solved.
The essence of the communication protocol is a data format, which defines the meaning represented by each part of the transmission data, and because the serialization and anti-serialization processes of the protocol are different, if each protocol is independently developed, the code quality may be uneven and a large amount of repeated work exists, so that the common part of different protocols is abstracted at the software level.
Disclosure of Invention
The invention aims to provide a custom protocol data acquisition method to solve the problems in the background technology.
In order to achieve the above purpose, the present invention provides the following technical solutions: a self-defined protocol data acquisition method comprises the following steps:
A. based on the acquisition function of the NLink edge gateway, the NLink edge gateway is enabled to have the configurable and dynamically expandable self-defined protocol acquisition capacity;
B. adding a protocol in a custom protocol page, and filling a CARJIMI protocol name;
C. newly adding a message under the CARJIMI protocol, filling out the name of an OutVoltage message, automatically loading fixed head and tail fields of the protocol to which the message belongs, and not modifying the fields;
D. synchronizing the json configuration file to an end module, analyzing the configuration file by the end module, and generating a message serialization module, a message deserialization module and an automatic response module according to protocol definition rules;
E. the terminal module fills in ip and port and initiates connection, a user can send json-format service data to the terminal module through the mqtt, wherein a key is a message field, a value is a corresponding parameter value, the terminal module transmits the service data to the serialization module to obtain a message, the message is transmitted to equipment at the other end through a link, and when the terminal module receives the data of the equipment, the message is transmitted to the deserialization module to obtain the service data and is pushed out through the mqtt;
F. opening a debugging window of the end module, wherein the lower half part is a message definition window, the left upper part is provided with a positive and negative serialization tag page, and the right upper part is a debugging function;
G. with the access of more devices, a user can analyze and send and receive the messages only by configuring more protocol definitions and messages according to the protocol of the devices.
Preferably, the protocol definition includes a protocol name, a message format, a size end, a message length, a fixed header field, and a fixed tail field, where the message format includes: fixed head, fixed tail, fixed head tail, fixed length, fixed separator; the size end is the storage order per 2 bytes; the message length is the total length of the data representing the subsequent n fields of a certain address; the fixed header field refers to n fields of the header shared by all messages under the protocol, and the difference between the messages is that the values of the fields are different; the fixed tail field refers to n tail fields shared by all messages under a protocol, and the difference between the messages is that the values of the fields are different; all messages under the protocol follow the definition of the protocol.
Preferably, the message definition is a format definition of a communication message, and the format of the message is composed of a plurality of fields, each field describes a business meaning of data in the message, including a field name, a field description, a position, a length, a data type, a field content and a data conversion mode, wherein the field type includes: constant, parameter, number, length, check, dynamic parameter, dynamic length, start-end position, repetition array; constant, i.e. static data, does not change in the message; parameters, i.e., dynamic data, which vary according to the incoming parameters but are fixed in length; the number is the number of elements of the repeated array in the message; the length is the byte length of the selected field in the message; checking, namely checking values of selected fields in the message, wherein a user can select various checking functions; dynamic parameters are parameters with unfixed length; the dynamic length, i.e. the field depends on the values of other fields to determine the type and length of the field; the starting and ending position, i.e. the length and position of the field, is relatively special, not in byte units, but in bit units; the repeated array is continuous n groups of fields, each group is composed of a plurality of fields with the same structure, and the data conversion mode defines spel expressions of serialization and deserialization.
Preferably, the automatic response module is: the gateway receives the message, the user only needs to start the response message, select the message to respond to the current message, fill in a section of expression, the expression can acquire the data of the current message, execute the expression, obtain the parameter data required by the response message, and the system automatically sequences the parameter data into the response message and sends the response message.
Preferably, the message serialization module is: the protocol definition module and the message definition module are used for obtaining a protocol definition file, and the message serialization module loads the protocol definition file and can then serialize the json format business data into a binary message.
Preferably, the message deserialization module is: the protocol definition module and the message definition module are used for obtaining a protocol definition file, and the message deserialization module is used for loading the protocol definition file, then identifying the binary message and deserializing the service data in the corresponding json format.
Preferably, the end module is: the user-defined protocol transmits data, the collector can be a client or a server, the terminal module can specify the connection mode of the collector, and after the connection is established successfully, the message positive and negative serialization module can normally communicate on the connection and send and receive messages.
Preferably, the debugging window comprises three windows, namely a message window, a binary message received and sent by the terminal module and service data corresponding to the message can be checked in real time; secondly, an error window is used for checking the error information reported by all modules in real time; and thirdly, a message definition window can modify the message in real time and has the functions of directly calling the connection and disconnection of the terminal module, sending the message, analyzing the message and the like.
Preferably, the message format of the CARJIMI protocol is a fixed head-tail type, a big end, and according to the service definition of the protocol, the message creates, adds, modifies and deletes the self-field of the message between the head and the tail.
Compared with the prior art, the invention has the following beneficial effects:
according to the invention, the function of the custom protocol is configured through the edge gateway, so that the edge gateway can support a dynamic expansion protocol, collect data of more kinds of equipment, and when a user OT system (operation technical system) integrates new equipment, such as fire-fighting equipment, vehicle-mounted equipment, AGV (automatic guided vehicle) equipment and the like, by adopting equipment manufacturers to have a communication protocol, the user can collect data of the new protocol in one edge gateway by only adding the new protocol on the edge gateway according to a format defined by the protocol, and report the collected data to an OT system through unified Http and MQTT protocols, thereby reducing the cost of independently developing each protocol or accessing new edge gateway hardware cost, and unifying the analysis mode of the protocol and the reported format.
Drawings
FIG. 1 is a schematic diagram of a protocol definition module according to the present invention;
FIG. 2 is a schematic diagram of a message definition module according to the present invention;
FIG. 3 is a schematic diagram of a debug window according to the present invention;
FIG. 4 is a schematic diagram of the configuration of constants of the present invention;
FIG. 5 is a schematic diagram of a configuration of the length of the present invention;
FIG. 6 is a schematic diagram of the configuration of the parameters of the present invention;
FIG. 7 is a schematic diagram of a configuration of the verification of the present invention;
FIG. 8 is a schematic diagram of a number of configurations of the present invention;
FIG. 9 is a schematic diagram of the configuration of dynamic parameters of the present invention;
FIG. 10 is a schematic diagram of the dynamic length configuration of the present invention;
FIG. 11 is a schematic diagram of a configuration of a repeating array of the present invention;
FIG. 12 is a schematic view of the configuration of the start and end positions of the present invention;
FIG. 13 is a schematic diagram of an auto-response configuration of the present invention;
FIG. 14 is a diagram of a protocol and the following messages according to the present invention;
FIG. 15 is a schematic diagram of the positive and negative serialization of the test of the present invention.
Description of the embodiments
The following description of the embodiments of the present invention will be made clearly and completely with reference to the accompanying drawings, in which it is apparent that the embodiments described are only some embodiments of the present invention, but not all embodiments. All other embodiments, which can be made by those skilled in the art based on the embodiments of the invention without making any inventive effort, are intended to be within the scope of the invention.
Referring to fig. 1-15, a custom protocol data collection method includes the following steps:
A. based on the acquisition function of the NLink edge gateway, the NLink edge gateway is enabled to have the configurable and dynamically expandable self-defined protocol acquisition capacity;
B. adding a protocol in a custom protocol page, and filling a CARJIMI protocol name;
C. newly adding a message under the CARJIMI protocol, filling out the name of an OutVoltage message, automatically loading fixed head and tail fields of the protocol to which the message belongs, and not modifying the fields;
D. synchronizing json configuration files to an end module, analyzing the configuration files by the end module, and generating a message serialization module, a message deserialization module and an automatic response module according to protocol definition rules, wherein the 3 modules are codes capable of identifying and processing the messages;
E. the terminal module fills in ip and port and initiates connection, a user can send json-format service data to the terminal module through the mqtt, wherein a key is a message field, a value is a corresponding parameter value, the terminal module transmits the service data to the serialization module to obtain a message, the message is transmitted to equipment at the other end through a link, and when the terminal module receives the data of the equipment, the message is transmitted to the deserialization module to obtain the service data and is pushed out through the mqtt;
F. the debugging window of the end module is opened, referring to fig. 3, the lower half part is a message definition window which can be modified and can be filled with field values, a sending button can send out a message, the sent and received data is checked at the upper left corner, the upper left part is provided with a positive and negative serialization tag page, only serialization and reverse serialization can be performed, and the message is not sent, referring to fig. 15, the upper right part is a debugging function, error information in the receiving and sending process is displayed, and referring to fig. 3;
G. with the access of more devices, a user can analyze and send and receive the messages only by configuring more protocol definitions and messages according to the protocol of the devices.
The protocol definition comprises a protocol name, a message format, a size end, a message length, a fixed head field and a fixed tail field, wherein the message format comprises: fixed head, fixed tail, fixed head tail, fixed length, fixed separator; the size end is the storage order per 2 bytes; the message length is the total length of the data representing the subsequent n fields of a certain address; the fixed header field refers to n fields of the header shared by all messages under the protocol, and the difference between the messages is that the values of the fields are different; the fixed tail field refers to n tail fields shared by all messages under a protocol, and the difference between the messages is that the values of the fields are different; all messages under the protocol follow the definition of the protocol.
The message definition, that is, the format definition of the communication message, the format of the message is composed of a plurality of fields, each field describes the business meaning of the data in the message, including field name, field description, position, length, data type, field content and data conversion mode, in order to flexibly adapt to business logic of various different protocol messages, the field type and the data conversion mode functions are particularly important, wherein, the field type comprises: constant, parameter, number, length, check, dynamic parameter, dynamic length, start-end position, repetition array; constant, i.e. static data, does not change in the message; parameters, i.e., dynamic data, which vary according to the incoming parameters but are fixed in length; the number is the number of elements of the repeated array in the message; the length is the byte length of the selected field in the message; checking, namely checking values of selected fields in the message, wherein a user can select various checking functions; dynamic parameters are parameters with unfixed length; the dynamic length, i.e. the field depends on the values of other fields to determine the type and length of the field; the starting and ending position, i.e. the length and position of the field, is relatively special, not in byte units, but in bit units; the repeated array is continuous n groups of fields, each group is composed of a plurality of fields with the same structure, the data conversion mode defines spel expressions of serialization and inverse serialization, the field types and the data conversion are mutually matched to form a flexible expression mode, and most of newspaper word segment definitions can be expressed.
The automatic response module is as follows: the gateway receives the message, sometimes needs the upper layer system to respond, sends out the response message, under some simple service scenes, it is troublesome to write a response code in the upper layer system alone, the automatic response function can help the user to send the response message directly at the gateway layer according to a certain rule, the user only needs to start the response message and select which message is used for responding to the current message, and fill in a section of expression, the expression can acquire the data of the current message, and execute the expression to obtain the parameter data needed by the response message, and the system automatically sequences the parameter data into the response message and sends the response message.
The message serialization module is as follows: the protocol definition module and the message definition module are used for obtaining a protocol definition file, and the message serialization module loads the protocol definition file and can then serialize the json format business data into a binary message.
The message deserialization module is as follows: the protocol definition module and the message definition module are used for obtaining a protocol definition file, and the message deserialization module is used for loading the protocol definition file, then identifying the binary message and deserializing the service data in the corresponding json format.
The end module is as follows: the user-defined protocol transmits data, the collector can be a client or a server, the terminal module can specify the connection mode of the collector, and after the connection is established successfully, the message positive and negative serialization module can normally communicate on the connection and send and receive messages.
The debugging window comprises three windows, namely a message window, a binary message which can be received and sent by the terminal module and service data corresponding to the message can be checked in real time; secondly, an error window is used for checking the error information reported by all modules in real time; and thirdly, a message definition window can modify the message in real time and has the functions of directly calling the connection and disconnection of the terminal module, sending the message, analyzing the message and the like, and because the definition of the protocol message is not performed on the spot, one field is configured and verified, the debugging window is a key tool capable of being configured successfully finally.
The message format of the carrjimi protocol is a fixed-head-tail type, big-end, and according to the service definition of the protocol, the fixed-head includes n fields, here exemplified by 3 fields: start bit Begin, message length body length, protocol number MessageType. The fixed tail includes n fields, here exemplified by 3 fields: the method comprises the steps of (1) setting up, adding, modifying and deleting the fields of a message between a head and a tail according to an information serial number serialNumx, an error check CrcLtu and a Stop bit Stop, and filling corresponding field information, wherein constant configuration needs to be filled with 16-system data at the beginning of 0x, and referring to FIG. 4; the length configuration requires that n continuous fields of the message be selected first, and the number of bytes in these fields is represented, see fig. 5; the configuration of parameters does not require filling in, as the data comes from the incoming parameters, see fig. 6; the configuration of the check requires selection of a check method and n check fields, refer to fig. 7; configuration of the number requires selection of a field whose type is a repetition array, representing the number of repetition arrays, refer to fig. 8; the configuration of dynamic parameters does not require filling in content, its length is dynamic, refer to fig. 9; the configuration of the dynamic length requires setting the data type and length for different conditions, refer to fig. 10; the configuration of the repetition array requires selecting a set of fields, meaning that the set of fields will be repeated n consecutive times, see fig. 11; configuration of the start and end positions requires specification of specific bit indexes, refer to fig. 12; automatic corresponding configuration requires designating corresponding packets and response expressions, and referring to fig. 13, through configuration of multiple messages of a protocol, a layer 2 tree protocol configuration is finally obtained, as shown in fig. 14, where the configuration may be saved as a file in json format.
The invention abstracts the common part of various protocols, and defines the part of protocol difference by a user in a page configuration mode, and realizes the dynamic expansion function of the core through the positive and negative serialization module.
The common part of the protocol includes:
the protocol comprises a plurality of messages;
the message format typically contains a header body tail 3 portion;
the header of the message will typically have a message type field and a message length field;
each part contains n fields, which are ordered;
the contents of the fields are all of the basic type: types such as boolean, one byte integer, 2 byte integers, 4 byte integers, 8 byte integers, 4 byte floating point numbers, 8 byte floating point numbers, character strings, etc.;
the format of the field is stored in a 2-system data format and can be mutually converted with the basic type, and the process is also called serialization and deserialization;
the messages are transmitted through the same underlying protocol: TCP/IP, serial port, UDP, etc.;
the message verification method generally adopts several general methods: CRC check, LRC check and the like;
the difference part of the protocol includes:
the number of messages contained in the protocol is different;
business meaning of the message;
the meaning of the service represented by the fields of the message is different;
the number of fields of the message is different;
accordingly, the invention allows users to add and delete protocols, messages and fields by designing a set of configuration pages, and then designs a set of general serialization modules and transmission modules (particularly referring to the following summary of the invention) to allow users to send and receive message data.
For example, the S7 communication protocol defines "establish communication request", "establish communication response", "read request", "read response", "write request", "write response", and the like, and each message includes a message header, a message body, and a message tail.
The message header mainly comprises information such as message type (used for distinguishing different message messages), message length (used for identifying the whole length of the message by the receiver) and the like; the message body mainly contains specific service information, such as information of point location address and reading length defined by a read request message, and information of point location address and writing value defined by a write request message; the message tail contains information such as message verification, message ending and the like.
The configuration by the protocol definition page at the edge gateway is: protocol, message under protocol, message head, message body, message tail function of message, and through the positive and negative serialization module of the invention, loading protocol configuration, positive and negative serialization module can identify the protocol, then analyze the message into text data that user and gateway program can identify, and give the data to terminal module, terminal module is responsible for outputting message according to standard format and standard transmission mode (such as MQTT).
The protocol configuration flow is as follows:
user-configuration protocol-protocol configuration page-loading protocol-positive and negative serialization module;
the main data flow process is as follows:
the device sends message data to the end module to be analyzed into identifiable text to the end module to be transmitted in standard.
Although embodiments of the present invention have been shown and described, it will be understood by those skilled in the art that various changes, modifications, substitutions and alterations can be made therein without departing from the principles and spirit of the invention, the scope of which is defined in the appended claims and their equivalents.
Claims (9)
1. A self-defined protocol data acquisition method is characterized in that: the method comprises the following steps:
A. based on the acquisition function of the NLink edge gateway, the NLink edge gateway is enabled to have the configurable and dynamically expandable self-defined protocol acquisition capacity;
B. adding a protocol in a custom protocol page, and filling a CARJIMI protocol name;
C. newly adding a message under the CARJIMI protocol, filling out the name of an OutVoltage message, automatically loading fixed head and tail fields of the protocol to which the message belongs, and not modifying the fields;
D. synchronizing the json configuration file to an end module, analyzing the configuration file by the end module, and generating a message serialization module, a message deserialization module and an automatic response module according to protocol definition rules;
E. the terminal module fills in ip and port and initiates connection, a user can send json-format service data to the terminal module through the mqtt, wherein a key is a message field, a value is a corresponding parameter value, the terminal module transmits the service data to the serialization module to obtain a message, the message is transmitted to equipment at the other end through a link, and when the terminal module receives the data of the equipment, the message is transmitted to the deserialization module to obtain the service data and is pushed out through the mqtt;
F. opening a debugging window of the end module, wherein the lower half part is a message definition window, the left upper part is provided with a positive and negative serialization tag page, and the right upper part is a debugging function;
G. with the access of more devices, a user can analyze and send and receive the messages only by configuring more protocol definitions and messages according to the protocol of the devices.
2. The method for collecting customized protocol data according to claim 1, wherein: the protocol definition comprises a protocol name, a message format, a size end, a message length, a fixed head field and a fixed tail field, wherein the message format comprises: fixed head, fixed tail, fixed head tail, fixed length, fixed separator; the size end is the storage order per 2 bytes; the message length is the total length of the data representing the subsequent n fields of a certain address; the fixed header field refers to n fields of the header shared by all messages under the protocol, and the difference between the messages is that the values of the fields are different; the fixed tail field refers to n tail fields shared by all messages under a protocol, and the difference between the messages is that the values of the fields are different; all messages under the protocol follow the definition of the protocol.
3. The method for collecting customized protocol data according to claim 1, wherein: the message definition is a format definition of a communication message, the format of the message is composed of a plurality of fields, each field describes business meaning of data in the message and comprises a field name, a field description, a position, a length, a data type, a field content and a data conversion mode, wherein the field type comprises: constant, parameter, number, length, check, dynamic parameter, dynamic length, start-end position, repetition array; constant, i.e. static data, does not change in the message; parameters, i.e., dynamic data, which vary according to the incoming parameters but are fixed in length; the number is the number of elements of the repeated array in the message; the length is the byte length of the selected field in the message; checking, namely checking values of selected fields in the message, wherein a user can select various checking functions; dynamic parameters are parameters with unfixed length; the dynamic length, i.e. the field depends on the values of other fields to determine the type and length of the field; the starting and ending position, i.e. the length and position of the field, is relatively special, not in byte units, but in bit units; the repeated array is continuous n groups of fields, each group is composed of a plurality of fields with the same structure, and the data conversion mode defines spel expressions of serialization and deserialization.
4. The method for collecting customized protocol data according to claim 1, wherein: the automatic response module is as follows: the gateway receives the message, the user only needs to start the response message, select the message to respond to the current message, fill in a section of expression, the expression can acquire the data of the current message, execute the expression, obtain the parameter data required by the response message, and the system automatically sequences the parameter data into the response message and sends the response message.
5. The method for collecting customized protocol data according to claim 1, wherein: the message serialization module is as follows: the protocol definition module and the message definition module are used for obtaining a protocol definition file, and the message serialization module loads the protocol definition file and can then serialize the json format business data into a binary message.
6. The method for collecting customized protocol data according to claim 1, wherein: the message deserialization module is as follows: the protocol definition module and the message definition module are used for obtaining a protocol definition file, and the message deserialization module is used for loading the protocol definition file, then identifying the binary message and deserializing the service data in the corresponding json format.
7. The method for collecting customized protocol data according to claim 1, wherein: the end module is as follows: the user-defined protocol transmits data, the collector can be a client or a server, the terminal module can specify the connection mode of the collector, and after the connection is established successfully, the message positive and negative serialization module can normally communicate on the connection and send and receive messages.
8. The method for collecting customized protocol data according to claim 1, wherein: the debugging window comprises three windows, namely a message window which can view binary messages received and sent by the terminal module and service data corresponding to the messages in real time; secondly, an error window is used for checking the error information reported by all modules in real time; and thirdly, a message definition window can modify the message in real time and has the functions of directly calling the connection and disconnection of the terminal module, sending the message, analyzing the message and the like.
9. The method for collecting customized protocol data according to claim 1, wherein: the message format of the CARJIMI protocol is a fixed head-tail type and a large end, and according to the service definition of the protocol, the message creates, adds, modifies and deletes the self-owned fields of the message between the head and the tail.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202311582856.XA CN117499380A (en) | 2023-11-24 | 2023-11-24 | Custom protocol data acquisition method |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202311582856.XA CN117499380A (en) | 2023-11-24 | 2023-11-24 | Custom protocol data acquisition method |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN117499380A true CN117499380A (en) | 2024-02-02 |
Family
ID=89684824
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202311582856.XA Pending CN117499380A (en) | 2023-11-24 | 2023-11-24 | Custom protocol data acquisition method |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN117499380A (en) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN118158291A (en) * | 2024-05-09 | 2024-06-07 | 大方智造(天津)科技有限公司 | Configurable communication transmission method |
-
2023
- 2023-11-24 CN CN202311582856.XA patent/CN117499380A/en active Pending
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN118158291A (en) * | 2024-05-09 | 2024-06-07 | 大方智造(天津)科技有限公司 | Configurable communication transmission method |
| CN118158291B (en) * | 2024-05-09 | 2024-07-23 | 大方智造(天津)科技有限公司 | Configurable communication transmission method |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN111083225B (en) | Data processing method and device in Internet of things platform and Internet of things platform | |
| CN107957940B (en) | Test log processing method, system and terminal | |
| CN117499380A (en) | Custom protocol data acquisition method | |
| CN108427731A (en) | Processing method, device, terminal device and the medium of page code | |
| CN111694561A (en) | Interface management method, device, equipment and storage medium | |
| US20210099538A1 (en) | Systems and methods for data exchange among network devices | |
| CN107015948A (en) | A kind of log information formatting method and system | |
| CN113190220A (en) | JSON file differentiation comparison method and device | |
| Bause et al. | Protocol Analysis Using a Timed Version of SDL. | |
| CN115794106A (en) | Method and system for analyzing configuration of binary protocol data of rail transit | |
| CN117278661B (en) | Industrial Internet of things multi-protocol analysis method and system | |
| CN111694752B (en) | Application testing method, electronic device and storage medium | |
| CN111767161A (en) | Remote calling depth recognition method and device, computer equipment and readable storage medium | |
| CN115543755B (en) | Performance supervision method, device, system, equipment and medium | |
| CN116647490A (en) | Aviation AFDX network data detection system | |
| CN115967604A (en) | Message transmission method and device, electronic equipment and computer readable storage medium | |
| CN117252188B (en) | Software image monitoring method and system based on artificial intelligence | |
| CN115396343B (en) | Front-end page performance detection method and device, computer equipment and storage medium | |
| CN111131477B (en) | Data processing method, device and equipment | |
| CN116319718B (en) | Cloud data storage processing method, system, equipment and medium | |
| CN118409744A (en) | Python code automatic generation method, system, medium and equipment based on interface document | |
| CN115577032A (en) | Method, device, terminal and storage medium for converting JSON (Java Server object notation) into SQL (structured query language) | |
| WO2002033553A1 (en) | Http request generation from xml definitions | |
| CN115442386A (en) | Method, device, equipment and medium for testing performance management interface | |
| CN116684335A (en) | System testing method, device, equipment and storage medium |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination |