CN112235302A - Protocol analysis method suitable for multiple buses - Google Patents
Protocol analysis method suitable for multiple buses Download PDFInfo
- Publication number
- CN112235302A CN112235302A CN202011103070.1A CN202011103070A CN112235302A CN 112235302 A CN112235302 A CN 112235302A CN 202011103070 A CN202011103070 A CN 202011103070A CN 112235302 A CN112235302 A CN 112235302A
- Authority
- CN
- China
- Prior art keywords
- frame
- data
- protocol
- length
- byte
- 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.)
- Granted
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 design general 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 0xAA), 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 of indefinite 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 finding 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 memnove (), and searching the byte head 0x550xAA again until the data is found.
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 this frame, and takes the word formed by the third and fourth two bytes of data, and this word represents the length FrmLen of this complete 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 larger than or equal to FrmLen, then turning to STEP5 to continue processing.
STEP5 checking integrity of data frame
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 discarding the frame and turning to STEP 2; 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 not consistent with the CRC value, turning to STEP 2;
STEP6, extracting 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 the same type of structural body by using the memory copy function memcpy, and then 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, the proposed protocol and protocol analysis method are suitable for 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 design general 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 0xAA), 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 of indefinite 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 finding 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 memnove (), and searching the byte head 0x550xAA again until the data is found.
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 this frame, and takes the word formed by the third and fourth two bytes of data, and this word represents the length FrmLen of this complete 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 larger than or equal to FrmLen, then turning to STEP5 to continue processing.
STEP5 checking integrity of data frame
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 discarding the frame and turning to STEP 2; 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 not consistent with the CRC value, turning to STEP 2;
STEP6, extracting 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 the same type of structural body by using the memory copy function memcpy, and then 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 (8)
1. A protocol analysis method suitable for various buses is characterized by comprising the following steps:
STEP1, designing 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 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 pData and the length RecvLen into a packBuf;
STEP3, finding the frame header;
STEP4, after finding the frame head, 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, then turning to STEP5 to continue processing;
STEP5 checking the integrity of the data frame;
STEP6, extracting 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 the same type of structure body by using a memory copy function memcpy, and performing algorithm calculation and data display by using the structure body.
2. The method for resolving a protocol applicable to a plurality of buses according to claim 1, wherein in STEP1, the general communication protocol is a variable length protocol, and the protocol contents include a two-byte protocol 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 byte variable payload content, a two-byte CRC check, and a two-byte frame end.
3. The method for resolving protocol applicable to multiple buses of claim 2, wherein in STEP1, two bytes of a header of a protocol frame are 0x55 and 0 xAA; 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; the two bytes at the end of the frame are 0xAA and 0x 55.
4. The method according to claim 3, wherein in STEP3, the length RecvLen of the received data is determined, and the minimum length is set to 12 bytes; when RecvLen is greater than 12 bytes, first determine if the first two bytes are not 0x55 and 0xAA, if not, discard the first two bytes and find the byte header 0x550xAA again until found.
5. The protocol parsing method for multiple buses as claimed in claim 4, wherein in STEP STEP3, the memory move method memmove () is used to move the data starting from the third byte to the beginning of the buffer, and then the byte header 0x550xAA is found again.
6. The method of claim 5, wherein in STEP4, after finding the frame header, the processing pointer TackPtr is moved backward by two bits, and when TackPtr points to the length information of the frame, the word formed by the third and fourth two bytes of data is taken, and the word indicates the length FrmLen of the whole frame.
7. The method for resolving a protocol applicable to a plurality of buses according to claim 6, wherein in STEP5, the process of checking the integrity of the data frame is:
after receiving a frame of complete data, judging whether the ending is 0xAA0x55 or not according to the frame length Frmlen, if not, directly abandoning the frame and turning to STEP 2; in the case that the frame header and the frame end are all found, the processing pointer TackPtr is moved to the position of FrmLen-4, the CRC value CRC _ get in the frame protocol is taken out, the CRC calculation method is used for calculating the CRC value of the frame, the CRC _ get value and the CRC value are compared, if the CRC _ get value and the CRC value are consistent, the STEP6 is switched to, and if the CRC _ get value and the CRC value are not consistent, the STEP2 is switched to.
8. The method according to claim 7, wherein when the inter-device communication function migrates from one bus to another, the underlying bus driver function of the device is modified to perform the migration of the relevant portion 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 true CN112235302A (en) | 2021-01-15 |
| CN112235302B 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) |
Cited By (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN113422738A (en) * | 2021-05-18 | 2021-09-21 | 上海赫千电子科技有限公司 | MCU communication service method of intelligent host |
| CN113609518A (en) * | 2021-06-18 | 2021-11-05 | 天津津航计算技术研究所 | Message protocol overtime retransmission method and system based on associated container map |
| CN113824621A (en) * | 2021-09-22 | 2021-12-21 | 石家庄通合电子科技股份有限公司 | CAN communication method based on signals and CAN controller |
| CN113973088A (en) * | 2021-05-18 | 2022-01-25 | 上海赫千电子科技有限公司 | MCU communication service system of intelligent host |
| 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博客》 * |
Cited By (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN113422738A (en) * | 2021-05-18 | 2021-09-21 | 上海赫千电子科技有限公司 | MCU communication service method of intelligent host |
| CN113973088A (en) * | 2021-05-18 | 2022-01-25 | 上海赫千电子科技有限公司 | MCU communication service system of intelligent host |
| CN113609518A (en) * | 2021-06-18 | 2021-11-05 | 天津津航计算技术研究所 | Message protocol overtime retransmission method and system based on associated container map |
| CN113609518B (en) * | 2021-06-18 | 2023-12-12 | 天津津航计算技术研究所 | Message protocol timeout retransmission method and system based on association container map |
| CN113824621A (en) * | 2021-09-22 | 2021-12-21 | 石家庄通合电子科技股份有限公司 | 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 |
Also Published As
| Publication number | Publication date |
|---|---|
| CN112235302B (en) | 2023-03-24 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN112235302B (en) | Protocol analysis method suitable for multiple buses | |
| US10673650B2 (en) | Programmable tunnel creation for hardware-based packet processing | |
| US7848332B2 (en) | Method and apparatus for classifying a network protocol and aligning a network protocol header relative to cache line boundary | |
| US9860168B1 (en) | Network packet header modification for hardware-based packet processing | |
| CN108306835B (en) | Input caching and data forwarding method of Ethernet switch | |
| US20120195208A1 (en) | Programmable multifield parser packet | |
| 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 | |
| US9565251B2 (en) | Method and apparatus to reduce FLASH memory device programming time over a C.A.N. bus | |
| WO2014135038A1 (en) | Packet transmission method and device based on pcie bus | |
| CN113411380B (en) | Processing method, logic circuit and equipment based on FPGA (field programmable gate array) programmable session table | |
| CN111988231B (en) | Mask quintuple rule matching method and device | |
| US10104205B2 (en) | Flexible data packet information mapping and modification | |
| EP2919433A1 (en) | Method and device for communication protocol processing | |
| CN113783800A (en) | Data packet processing method and device, computer equipment and readable storage medium | |
| WO2010143686A1 (en) | Automobile control system and electronic control unit | |
| CN105207984B (en) | Method for representing universal format header using consecutive bytes and apparatus therefor | |
| 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 | |
| US20060274762A1 (en) | Method and system for supporting efficient and cache-friendly TCP session lookup operations based on canonicalization tags | |
| 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 | |
| US7581163B1 (en) | Detection of corrupted memory pointers within a packet-processing device |
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 |