CN112235302B - Protocol analysis method suitable for multiple buses - Google Patents
Protocol analysis method suitable for multiple buses Download PDFInfo
- Publication number
- CN112235302B CN112235302B CN202011103070.1A CN202011103070A CN112235302B CN 112235302 B CN112235302 B CN 112235302B CN 202011103070 A CN202011103070 A CN 202011103070A CN 112235302 B CN112235302 B CN 112235302B
- Authority
- CN
- China
- Prior art keywords
- frame
- data
- byte
- protocol
- length
- 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.)
- Active
Links
Images
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/22—Parsing or analysis of headers
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L1/00—Arrangements for detecting or preventing errors in the information received
- H04L1/004—Arrangements for detecting or preventing errors in the information received by using forward error control
- H04L1/0056—Systems characterized by the type of code used
- H04L1/0061—Error detection codes
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
- H04L12/40—Bus networks
-
- 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/06—Notations for structuring of protocol data, e.g. abstract syntax notation one [ASN.1]
-
- 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/18—Multiprotocol handlers, e.g. single devices capable of handling multiple protocols
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Security & Cryptography (AREA)
- Communication Control (AREA)
Abstract
The invention discloses a method suitable for various buses, which completely does not need to redesign a protocol when replacing a bus or a system shift value and improves the adaptability among systems. The protocol and the protocol analysis method provided by the invention are suitable for various buses, the bus protocol design and the bus protocol analysis method are separated from the characteristics of a bus physical layer, and the protocol design and the bus protocol analysis method have higher efficiency and stronger value shifting property.
Description
Technical Field
The invention belongs to the technical field of aerospace system data communication, and relates to a protocol analysis method suitable for multiple buses.
Background
The aerospace system has various common buses, such as a CAN bus, a serial port, an Ethernet UDP protocol, an Ethernet TCP protocol and the like, and all the communication buses belong to serial communication buses. The recovery of the data on the serial bus is protocol analysis, which is usually bus application layer message, and the data on the bus is recovered to the maximum extent by applying mechanisms such as packet framing and fault tolerance.
Disclosure of Invention
Objects of the invention
In the aerospace field, the communication among systems has a plurality of bus modes, common buses have serial ports 422 buses, CAN buses and Ethernet, different protocols are defined by different bus habits, for example, each CAN frame data of the CAN buses has only 8 bytes, the protocol CAN only define short frames or occupy effective bytes of the CAN data to mark CAN frame serial numbers and the like, and if the CAN buses are changed into other buses, the original protocol is difficult to use in the intersystem cascade. Similarly, the ethernet usually adopts UDP protocol, and does not consider the problems of framing packet loss and the like, so the protocol design usually does not include frame headers, frame bit checks and the like, and also when the bus is replaced or the value is shifted to other systems, the bus protocol needs to be redesigned.
The invention provides a method suitable for various buses on the basis of the traditional bus protocol analysis method, and when the bus is replaced or the system value is shifted, the protocol is not required to be redesigned completely, so that the adaptability among the systems is improved.
(II) technical scheme
In order to solve the above technical problem, the present invention provides a protocol parsing method suitable for multiple buses, comprising the following steps:
STEP1 designing a universal communication protocol
The protocol is a variable length protocol, and the protocol content comprises a protocol header of two bytes (the two bytes of the protocol header are 0x55 and 0 xAA), a frame length of two bytes (including the length of all bytes from the header to the tail), a frame type of one byte (a command frame is represented by 0x01, and a data frame is represented by 0x 02), a destination address of one byte, a source address of one byte, a function code of two bytes, variable-byte load content, a CRC check of two bytes, and a frame end of two bytes (the two bytes of the frame end are 0xAA and 0x 55).
STEP2, packaging the driving bottom layer receiving functions of various buses into a uniform receiving function DataRecv function with consistent interfaces, returning the received data length RecvLen by the DataRecv function, storing the data in a buffer area pointed by a pointer pData, and copying the data with the starting address of pData and the length of RecvLen into a TackBuf.
STEP3 searching frame header
The length RecvLen of the received data needs to be judged first, and the minimum length is set to be 12 bytes; when RecvLen is larger than 12 bytes, firstly judging whether the first two bytes are 0x550xAA, if not, discarding the first two bytes, moving the data starting from the third byte to the beginning of the buffer by using a memory moving method memmove (), and searching the byte head 0x550xAA again until the data is found.
STEP4, after finding the frame header, moving the processing pointer TackPtr backward by two bits, wherein the TackPtr points to the length information of the frame, and a word composed of the third byte data and the fourth byte data is taken, and the word represents the length FrmLen of the whole frame. And comparing the lengths of the FrmLen and the RecvLen, and when the RecvLen is more than or equal to the FrmLen, receiving a complete frame and continuing the processing. Otherwise, continuing to receive the data until the received data RecvLen is more than or equal to FrmLen, turning to STEP5, and continuing to process.
STEP5 checking the integrity of data frames
After receiving a frame of complete data, judging whether the ending is 0xAA0x55 or not according to the frame length FrmLen, and if not, directly abandoning the frame and turning to STEP2; under the condition that the frame head and the frame tail are all found, a processing pointer TackPtr is moved to the position of FrmLen-4, a CRC value CRC _ get in the frame protocol is taken out, a CRC calculation method is used for calculating the CRC value of the frame, the CRC value CRC _ get and the CRC value are compared, if the CRC value CRC _ get is consistent, STEP6 is carried out, and if the CRC value is inconsistent, STEP2 is carried out;
STEP6, taking out the frame type, judging whether the frame is a data frame or a command frame, and judging whether the frame data is the data required by the system according to the destination address and the ID of the system.
STEP7, judging the type of the data according to the function code, copying the data to a structural body of the same type by using a memory copy function memcpy, and directly using the structural body to perform algorithm calculation and data display.
(III) advantageous effects
The protocol analysis method suitable for various buses provided by the technical scheme is applicable to various buses, the bus protocol design and analysis method are separated from the characteristics of the physical layer of the bus, and the protocol design and analysis method has higher efficiency and higher value shifting performance.
Drawings
FIG. 1 is a flow chart of the method of the present invention.
Detailed Description
In order to make the objects, contents, and advantages of the present invention clearer, the following detailed description of the embodiments of the present invention will be made in conjunction with the accompanying drawings and examples.
In order to unify different types of buses in the inter-device communication process, different communication protocols are used, the traditional system design considers the uniformity of the inter-device communication protocols less, and the hardware bus is often replaced to cause the bus protocol to need to be modified. A general bus protocol is provided, which CAN be used in CAN bus protocol and serial port 422 bus protocol. A serial port 485 bus protocol, an ethernet UDP protocol, an ethernet TCP protocol, etc. are described with reference to fig. 1, and the method for analyzing the general protocol specifically includes the following steps:
STEP1 designing a universal communication protocol
The protocol is a variable length protocol, the protocol content comprises a protocol header of two bytes (the two bytes of the protocol header are 0x55 and 0 xAA), a frame length of two bytes (including the length of all bytes from the header to the tail), a frame type of one byte (a command frame is represented by 0x01, and a data frame is represented by 0x 02), a destination address of one byte, a source address of one byte, a function code of two bytes, payload content with variable bytes, a CRC check of two bytes, and a frame end of two bytes (the two bytes of the frame end are 0xAA and 0x 55).
STEP2, packaging the driving bottom layer receiving functions of various buses into a uniform receiving function DataRecv function with consistent interfaces, returning the received data length RecvLen by the DataRecv function, storing the data in a buffer area pointed by a pointer pData, and copying the data with the starting address of pData and the length of RecvLen into a TackBuf.
STEP3 searching frame header
The length RecvLen of the received data needs to be judged first, and the minimum length is set to be 12 bytes; when RecvLen is larger than 12 bytes, firstly judging whether the first two bytes are 0x550xAA, if not, discarding the first two bytes, moving the data starting from the third byte to the beginning of the buffer by using a memory moving method memmove (), and searching the byte head 0x550xAA again until the data is found.
STEP4, after finding the frame header, moving the processing pointer TackPtr backward by two bits, wherein the TackPtr points to the length information of the frame, and a word composed of the third byte data and the fourth byte data is taken, and the word represents the length FrmLen of the whole frame. And comparing the lengths of the FrmLen and the RecvLen, and when the RecvLen is more than or equal to the FrmLen, receiving a complete frame and continuing the processing. Otherwise, continuing to receive the data until the received data RecvLen is more than or equal to FrmLen, then turning to STEP5 to continue processing.
STEP5 checking the integrity of data frames
After receiving a frame of complete data, judging whether the ending is 0xAA0x55 or not according to the frame length FrmLen, if not, directly discarding the frame, and turning to STEP2; under the condition that the frame head and the frame tail are all found, moving a processing pointer TackPtr to the position of FrmLen-4, taking out a CRC value CRC _ get in the frame protocol, calculating the CRC value of the frame by using a CRC calculation method, comparing the CRC _ get value with the CRC value, if the CRC _ get value is consistent with the CRC value, turning to STEP6, and if the CRC _ get value is inconsistent with the CRC value, turning to STEP2;
STEP6, taking out the frame type, judging whether the frame is a data frame or a command frame, and judging whether the frame data is the data required by the system according to the destination address and the ID of the system.
STEP7, judging the type of the data according to the function code, copying the data to a structural body of the same type by using a memory copy function memcpy, and directly using the structural body to perform algorithm calculation and data display.
In the method, when the communication function between the devices is transferred from one bus to another bus, the bus driving function at the bottom layer of the devices is directly modified to complete the transplantation of the relevant part of the communication protocol without modifying the part of codes.
The above description is only a preferred embodiment of the present invention, and it should be noted that, for those skilled in the art, several modifications and variations can be made without departing from the technical principle of the present invention, and these modifications and variations should also be regarded as the protection scope of the present invention.
Claims (1)
1. A protocol analysis method suitable for various buses is characterized by comprising the following steps:
STEP1, designing a general communication protocol;
STEP2, packaging the driving bottom layer receiving functions of various buses into a uniform receiving function DataRecv function with consistent interfaces, returning the DataRecv function to the received data length RecvLen, storing the data in a buffer area pointed by a pointer pData, and copying the data with the starting address pData and the length RecvLen into a tapuf;
STEP3, searching frame headers;
STEP4, after finding out the frame header, determining the length FrmLen of the whole frame; comparing the size of the FrmLen with the size of the received data length RecvLen, and when the RecvLen is more than or equal to the FrmLen, receiving a complete frame and continuing processing; otherwise, continuing to receive the data until the received data RecvLen is more than or equal to FrmLen, turning to STEP5, and continuing to process;
STEP5, checking the integrity of the data frame;
STEP6, taking out the frame type, judging whether the frame is a data frame or a command frame, and judging whether the frame data is the data required by the system according to the destination address and the ID of the system.
STEP7, judging the type of the data according to the function code, copying the data to a structural body of the same type by using a memory copy function memcpy, and performing algorithm calculation and data display by using the structural body;
in STEP1, the general communication protocol is a variable length protocol, and the protocol content includes a two-byte protocol frame header, a two-byte frame length, a one-byte frame type, a one-byte destination address, a one-byte source address, a two-byte function code, a load content with an indefinite number of bytes, a two-byte CRC check, and a two-byte frame end;
in STEP1, two bytes of the protocol frame header are 0x55 and 0xAA; the frame length is the length of all bytes from the frame head to the frame tail; in the frame type, a command frame is represented by 0x01, and a data frame is represented by 0x 02; two bytes at the end of the frame are 0xAA and 0x55;
in the STEP STEP3, the length RecvLen of the received data is judged first, and the minimum length is set to be 12 bytes; when the RecvLen is larger than 12 bytes, firstly judging whether the first two bytes are 0x55 and 0xAA, if not, discarding the first two bytes, and searching the byte head 0x550xAA again until the byte head is found;
in STEP3, using memory moving method memmove () to move the data of the third byte start to the beginning of the buffer, and then searching the byte header 0x550xAA again;
in STEP4, after finding the frame header, moving the processing pointer tapptr backward by two bits, at this time, tapptr points to the length information of the frame, and taking a word composed of the third and fourth two-byte data, where the word represents the length FrmLen of the whole frame;
in STEP5, the process of verifying the integrity of the data frame is as follows:
after receiving a frame of complete data, judging whether the end is 0xAA0x55 according to the frame length Frmlen, if not, directly abandoning the frame, and turning to STEP2; under the condition that the frame head and the frame tail are all found, moving a processing pointer TackPtr to the position of FrmLen-4, taking out a CRC value CRC _ get in the frame protocol, calculating the CRC value of the frame by using a CRC calculation method, comparing the CRC _ get value with the CRC value, if the CRC _ get value is consistent with the CRC value, turning to STEP6, and if the CRC _ get value is inconsistent with the CRC value, turning to STEP2;
when the communication function between the devices is transferred from one bus to another bus, the bus driving function of the device bottom layer is modified to complete the transplantation of the relevant part of the communication protocol.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202011103070.1A CN112235302B (en) | 2020-10-15 | 2020-10-15 | Protocol analysis method suitable for multiple buses |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202011103070.1A CN112235302B (en) | 2020-10-15 | 2020-10-15 | Protocol analysis method suitable for multiple buses |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN112235302A CN112235302A (en) | 2021-01-15 |
| CN112235302B true CN112235302B (en) | 2023-03-24 |
Family
ID=74113750
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202011103070.1A Active CN112235302B (en) | 2020-10-15 | 2020-10-15 | Protocol analysis method suitable for multiple buses |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN112235302B (en) |
Families Citing this family (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN113422738B (en) * | 2021-05-18 | 2023-07-21 | 上海赫千电子科技有限公司 | MCU communication service method of intelligent host |
| CN113973088A (en) * | 2021-05-18 | 2022-01-25 | 上海赫千电子科技有限公司 | MCU communication service system of intelligent host |
| CN113609518B (en) * | 2021-06-18 | 2023-12-12 | 天津津航计算技术研究所 | Message protocol timeout retransmission method and system based on association container map |
| CN113824621B (en) * | 2021-09-22 | 2023-04-14 | 石家庄通合电子科技股份有限公司 | CAN communication method based on signals and CAN controller |
| CN114979307A (en) * | 2022-04-19 | 2022-08-30 | 杭州涂鸦信息技术有限公司 | Communication protocol analysis method, intelligent terminal and storage medium |
Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN107147657A (en) * | 2017-05-31 | 2017-09-08 | 飞智控（天津）科技有限公司 | Suitable for the communication protocol of multimachine reliable communication, decoding method and communication apparatus |
| CN109739747A (en) * | 2018-12-13 | 2019-05-10 | 西安现代控制技术研究所 | A kind of general analytic method of serial communication information protocol |
| CN110311848A (en) * | 2019-08-02 | 2019-10-08 | 杭州远流科技有限公司 | A kind of method that Modbus RTU communications protocol improves communication efficiency |
-
2020
- 2020-10-15 CN CN202011103070.1A patent/CN112235302B/en active Active
Patent Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN107147657A (en) * | 2017-05-31 | 2017-09-08 | 飞智控（天津）科技有限公司 | Suitable for the communication protocol of multimachine reliable communication, decoding method and communication apparatus |
| CN109739747A (en) * | 2018-12-13 | 2019-05-10 | 西安现代控制技术研究所 | A kind of general analytic method of serial communication information protocol |
| CN110311848A (en) * | 2019-08-02 | 2019-10-08 | 杭州远流科技有限公司 | A kind of method that Modbus RTU communications protocol improves communication efficiency |
Non-Patent Citations (1)
| Title |
|---|
| C++中TCP/IP按约定报文协议接收数据完成拼包;技术老虎;《CSDN博客》;20170711;第1-5页 * |
Also Published As
| Publication number | Publication date |
|---|---|
| CN112235302A (en) | 2021-01-15 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN112235302B (en) | Protocol analysis method suitable for multiple buses | |
| US7848332B2 (en) | Method and apparatus for classifying a network protocol and aligning a network protocol header relative to cache line boundary | |
| CN107395565B (en) | Serial port receiving preprocessing method under fixed-length single byte format message protocol | |
| CA2472908A1 (en) | Packet header compression system and method based upon a dynamic template creation | |
| CN113783800B (en) | Data packet processing method and device, computer equipment and readable storage medium | |
| US9565251B2 (en) | Method and apparatus to reduce FLASH memory device programming time over a C.A.N. bus | |
| CN113411380B (en) | Processing method, logic circuit and equipment based on FPGA (field programmable gate array) programmable session table | |
| WO2014135038A1 (en) | Packet transmission method and device based on pcie bus | |
| WO2010143686A1 (en) | Automobile control system and electronic control unit | |
| CN101969404A (en) | Method and equipment for processing messages | |
| CN109902055B (en) | SLIP coding data stream transmission method suitable for narrow-band data network | |
| US20060268867A1 (en) | TCP/IP reception processing circuit and semiconductor integrated circuit implementing the same | |
| CN113765892A (en) | System, method, and computer readable medium for adapting to network protocol updates | |
| CN105187330B (en) | Method for identifying packet structure using unique packet identifier and network switch | |
| US20090303999A1 (en) | Method And Device For Transmitting Data Packets | |
| US7181675B2 (en) | System and method for checksum offloading | |
| US5948079A (en) | System for non-sequential transfer of data packet portions with respective portion descriptions from a computer network peripheral device to host memory | |
| CN114422624B (en) | Data receiving method | |
| CN109979498A (en) | The method and device of the write-in of disk video data, reading | |
| US9247032B2 (en) | Method for offloading packet segmentations and device using the same | |
| US7581163B1 (en) | Detection of corrupted memory pointers within a packet-processing device | |
| US20110158119A1 (en) | Communication apparatus, processing method for the same, and computer-readable storage medium | |
| KR101353992B1 (en) | Method and device for data packet assembly | |
| JP4401910B2 (en) | Data communication apparatus and data communication method | |
| US20020078246A1 (en) | Method and system for network protocol processing |
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 | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |