CN115052052A - Information transmission method, device and controller based on ICAP (independent component analysis protocol) - Google Patents
Information transmission method, device and controller based on ICAP (independent component analysis protocol) Download PDFInfo
- Publication number
- CN115052052A CN115052052A CN202210445156.5A CN202210445156A CN115052052A CN 115052052 A CN115052052 A CN 115052052A CN 202210445156 A CN202210445156 A CN 202210445156A CN 115052052 A CN115052052 A CN 115052052A
- Authority
- CN
- China
- Prior art keywords
- control
- transmission
- terminal
- protocol
- session
- 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
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
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
- H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
- H04L63/0435—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload wherein the sending and receiving network entities apply symmetric encryption, i.e. same key used for encryption and decryption
-
- 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/24—Negotiation of communication capabilities
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Hardware Design (AREA)
- Computing Systems (AREA)
- General Engineering & Computer Science (AREA)
- Communication Control (AREA)
Abstract
An information transmission method, device and controller based on ICAP protocol, the said protocol includes the protocol header, the said method includes: the control terminal and the terminal carry out session negotiation through the session type message and establish communication connection with the terminal according to a negotiation result; the control end defines the type and the transmission mode of the information to be transmitted through the protocol header; and when the transmission mode is control transmission, the control end sends a control transmission type message to the terminal in a control transmission mode. The method can unify the communication protocols of OBD, VCI and other industrial control products, reduce repeated development and improve the stability of communication.
Description
Technical Field
The present application relates to the field of industrial control, and in particular, to an information transmission method, apparatus and controller based on an ICAP protocol.
Background
Existing industrial control products, such as On-Board Diagnostics (OBD), Vehicle-mounted self-diagnosis (VCI), and Vehicle Communication Interface (VCI), have no unified Communication protocol, and need to be researched and developed separately, so that the products are repeatedly developed, and thus, resources are wasted.
Disclosure of Invention
The application provides an information transmission method, an information transmission device and a controller based on an ICAP protocol.
According to a first aspect of the present application, there is provided an information transmission method based on an ICAP protocol, the protocol including a protocol header, the method including:
the control terminal and the terminal carry out session negotiation through the session type message and establish communication connection with the terminal according to a negotiation result;
the control end defines the type and the transmission mode of the information to be transmitted through the protocol header;
and when the transmission mode is control transmission, the control end sends a control transmission type message to the terminal in a control transmission mode.
Further, the protocol header includes the following fields:
the package attributes are: including a transmission mode, the transmission mode including a control transmission and a burst transmission;
command: command types are defined including session class messages, control transfer class messages, and burst transfer class messages.
Further, the control terminal sends a control transmission type message to the terminal through a control transmission mode, including:
the plurality of request messages sent by the control terminal and the corresponding response messages sent by the terminal can be transmitted out of order and in a nested manner.
Further, the controlling the transmission type message specifically includes: parameter setting, parameter inquiry, state reporting, equipment control and response.
According to a second aspect of the present application, there is provided a controller based on an ICAP protocol, the protocol including a protocol header, the controller comprising:
the negotiation module is used for carrying out session negotiation with the terminal through the session type message and establishing communication connection with the terminal according to a negotiation result;
the definition module is used for defining the information category and the transmission mode to be transmitted through the protocol header;
and the processing module is used for sending the control transmission type message to the terminal in a control transmission mode when the transmission mode is control transmission.
Further, the protocol header includes the following fields:
the package attributes are: including a transmission mode, the transmission mode including a control transmission and a burst transmission;
command: command types are defined including session class messages, control transfer class messages, and burst transfer class messages.
Further, the processing module includes:
a transmitting unit configured to transmit a plurality of pieces of request information;
and the receiving unit is used for receiving corresponding response information sent by the terminal, and the request information and the response information can be transmitted out of order and in a nested manner.
According to a third aspect of the present application, there is provided an information transmission apparatus based on an ICAP protocol, comprising:
a memory for storing a program;
a processor for implementing the above method by executing the program stored in the memory.
According to a fourth aspect of the present application, there is provided a computer readable storage medium storing a program executable by a processor to perform the method described above.
Owing to adopted above technical scheme, make the beneficial effect that this application possesses lie in:
the information transmission method based on the ICAP protocol provided by the embodiment of the application comprises the steps that a control terminal and a terminal carry out session negotiation through session type information, and communication connection is established with the terminal according to a negotiation result; the control end defines the type and the transmission mode of the information to be transmitted through the protocol header; when the transmission mode is control transmission, the control end sends control transmission type information to the terminal through a control transmission mode.
Drawings
FIG. 1 is a flow chart of a method in one embodiment of the present application;
FIG. 2 is a schematic diagram of program modules of a controller according to a second embodiment of the present application;
fig. 3 is a schematic diagram of program modules of a controller in another embodiment according to a second embodiment of the present application.
Detailed Description
The present invention will be described in further detail with reference to the following detailed description and accompanying drawings. Wherein like elements in different embodiments are numbered with like associated elements. In the following description, numerous details are set forth in order to provide a better understanding of the present application. However, those skilled in the art will readily recognize that some of the features may be omitted or replaced with other elements, materials, methods in different instances. In some instances, certain operations related to the present application have not been shown or described in this specification in order not to obscure the core of the present application with unnecessary detail, and it is not necessary for those skilled in the art to describe these operations in detail, so that they may be fully understood from the description in the specification and the general knowledge in the art.
Furthermore, the features, operations, or characteristics described in the specification may be combined in any suitable manner to form various embodiments. Also, the various steps or actions in the method descriptions may be transposed or transposed in order, as will be apparent to one of ordinary skill in the art. Thus, the various sequences in the specification and drawings are for the purpose of describing certain embodiments only and are not intended to imply a required sequence unless otherwise indicated where such sequence must be followed.
The ordinal numbers used herein for the components, such as "first," "second," etc., are used merely to distinguish between the objects described, and do not have any sequential or technical meaning. The term "connected" and "coupled" when used in this application, unless otherwise indicated, includes both direct and indirect connections (couplings).
The ICAP (industrial Control advanced Communication Protocol) in the present application belongs to a transport Protocol (which may correspond to a network layer or a transport layer in the OSI model). The protocol aims at unifying the communication regulations of OBD, VCI and other industrial control products, reducing repeated development and improving the stability of communication. The protocol is applied to communication between the application of a numerical control key machine product and a mechanical control module for the first time, gives consideration to classical Bluetooth and serial port communication at present, and can be expanded to USB communication and higher communication links.
The first embodiment is as follows:
as shown in fig. 1, in the information transmission method based on the ICAP protocol provided in the embodiment of the present application, the ICAP protocol includes a protocol header, and the method may include the following steps:
step 101: the control terminal and the terminal carry out session negotiation through the session type message, and establish communication connection with the terminal according to the negotiation result.
Further, the session negotiation includes communication rate negotiation and communication security negotiation.
The communication rate negotiation comprises the maximum baud rate of a communication channel and the maximum data flux which can be borne by both communication parties; the parameters of the rate negotiation include: receive buffer and transmit buffer size.
The communication security negotiation comprises a session initiator informing a symmetric encryption mode supported by a receiver, wherein the encryption mode comprises DES,3DES, AES or NONE; wherein NONE indicates no encryption.
The first step of session establishment is session negotiation, and two communication parties need to carry out comprehensive negotiation on the characteristics of a communication channel to be established and can establish the communication channel after finally reaching an agreement.
The communication rate negotiation comprises the maximum baud rate of the communication channel and the maximum data flux which can be borne by the applications of the two communication parties. The channel baud rate does not need to be transmitted, the maximum baud rate is already determined after the connection mode is determined, and the parameter is known by both sides. The maximum data throughput that an application can tolerate by itself is typically related to the buffer size and the processing speed of the data in the buffer. Therefore, there are 2 parameters for rate negotiation, that is, the size of the receiving buffer and the sending buffer of both communication parties, the endianness is from high to low:
| receiving buffer size | Transmit buffer size |
| 2bytes | 2bytes |
TABLE 1 Rate negotiation parameters Table
The communication security negotiation is a key step of confidentiality, and a session initiator informs a receiver of supported symmetric encryption modes including DES,3DES, AES and NONE. The full set is 4, and a subset of the support can be sent. The receiver selects one encryption mode according to self conditions, if NONE is selected, the encryption mode is not used, the message is transmitted in clear, and the characteristic can be only used in specific occasions, such as a research and development test stage, and the communication efficiency is improved in the occasions where one chip is difficult to monitor. This parameter is expressed in one byte, called the session option, and each of the 3-6 bits represents the support capability of an encryption scheme, as shown in the following table:
table 2 session option structure for rate negotiation parameters
If the session is established by the cube to force channel encryption, 0bit is set to 0, which indicates that communication without encryption is not supported, and the receiver cannot select a NON encryption mode, otherwise, the session cannot be established.
The idle window or heartbeat interval negotiation idle window refers to the measurement of communication activity, is the time of bus idle, and the session can be always kept valid in the idle window, and if the bus idle time exceeds the window time, the session can be invalid. The data consists of 4 bytes, 0 representing an infinitely long time window. The final result is based on the number of the response, if the sender gives a non-0 number, the receiver responds 0, and the sender has the right to refuse to continue the negotiation. When the flag in the session option selects the heartbeat interval, session maintenance will be based on the heartbeats, and the session will fail after a specified number of heartbeats have not been answered. And only selecting one of the idle window and the heartbeat interval, and maintaining the session by default by adopting the heartbeat. After the session is invalid, any received message is discarded without any response.
Step 102: the control end defines the information category and the transmission mode to be transmitted through the protocol header.
The protocol header may include the following fields:
the package attributes are: including a transmission mode, the transmission mode including a control transmission and a burst transmission;
command: command types are defined including session class messages, control transfer class messages, and burst transfer class messages.
Further, in an embodiment, the protocol header may specifically include the following fields:
| sign (sign) | Packet length | Protocol version | Package attributes | ID | Command | Data of | crc |
| 1byte | 1-4bytes | 0-1byte | 1byte | 1-4bytes | 1byte | nbytes | 1byte |
| 0x80 | High,LOW | - | - | - | - | - | - |
TABLE 3 protocol header component structure
Marking: a fixed 0x80 indicates that a packet is started and the flag may not be used for short-range communications.
Packet length: 1-4 bytes, the entire packet length, including the packet header, data payload, crc, facilitates parsing packet integrity.
Protocol version: 0-4 bytes, the upper 4 bits are primary version, the lower 4 bits are secondary version, at most 255 versions are supported, and 0 is reserved. The protocol version is set in order to make the protocol itself extensible and compatible, and the processing of messages by the message sender must be kept consistent, which is based on the protocol version information. The protocol supports a maximum of 255 versions, with 0 reserved, starting at a minimum at 0.1, major versions 0-0x0F, minor versions 1-0x 0F. For example, version: 0.1, 1.3, 15.15, etc. In one embodiment, the protocol header may also contain no protocol version field, such as the bluetooth BLE channel, whose single frame data length cannot exceed 20 bytes.
Further, in another embodiment, the protocol header may include the following fields: packet attributes, message ID, data, packet length, in this embodiment, the protocol header may not include the following fields: flags, protocol version, and command fields, such as bluetooth BLE channel.
The package attributes may be used to control the parsing and properties of the package. Packet attributes control the properties of the packet, such as parsing and interaction, and currently use 1 byte:
table 4 packet attribute field composition structure of protocol header
The three bit fields may be arbitrarily arranged in the byte, may be arranged adjacent to each other or at intervals, and may be arranged at the upper or lower position. In one embodiment, the lowest order 0 represents the transmission mode, 0 represents the control transmission, the order of the various control transmissions does not matter, and messages can be interspersed; 1 indicates a burst transfer, and the burst transfer surface needs to transfer a large amount of data at a time, and the period cannot be interrupted until the transfer is completed, and the control transfer or the next burst transfer cannot be started. Bits 1-2 indicate symmetric encryption, 00 indicates no encryption, 01 indicates DES encryption, 10 indicates 3DES encryption, and 11 indicates AES encryption, and generally, the encryption is a result of negotiation between both parties during session establishment, and it is not possible to simply and fixedly use a certain encryption, which is a gospel to an attacker, and only the dynamic negotiation encryption is more secure. Bit 3 indicates whether the data is compressed, 0 indicates no compression, the original byte content is transmitted, and 1 indicates that the byte compression strategy is adopted.
ID: namely, the message ID, the upper 4 bits are the session ID, the lower 4 bits are the packet sequence number during the session, and the lower 4 bits automatically start from 0 when they reach 0x 0F. The message ID is 1 byte in length and has the following composition structure:
| 7-4 | 3-0 |
| session ID | Intra-session message ID |
Table 5 message ID field composition structure of protocol header
During session establishment, bits 7-4 are always 0, after establishment, the session ID starts from 1, and after F is reached, the loop starts from 1, and the message ID rules are consistent, that is, the ID field does not have the condition of being equal to 0.
Command: 1 byte, 2 bits high is the command type, and 6 bits low is the subcommand. The command is 1 byte, the high 2bit is a type, and the low 6bit is a subclass, so that the design is convenient for command classification, and the logic is clearer. The command field includes the following:
| binary value | Name (R) |
| 00 | Session category messages |
| 01 | Control transmission classAuthentication messages |
| 10 | Burst transfer class message |
| 11 | Retention |
TABLE 6 Command field content of protocol header
Message subclass all 1 indicates this type of message reply message, but command byte 0xFF reserved is an invalid message class, since the 7-6 bit value 11 is a reserved value and 0xFF cannot occur. The session category message any reply has a definite subcategory with the purpose of unambiguously identifying all steps of the session establishment procedure, rather than an ambiguous general reply.
Data: the payload varies according to the command.
crc: the exclusive or value of 1 byte full packet data (except for the crc itself).
Step 103: and when the transmission mode is control transmission, the control end sends a control transmission type message to the terminal in a control transmission mode.
Further, step 103 may specifically include:
a plurality of request messages sent by the control end and corresponding response messages sent by the terminal can be transmitted in disorder and nesting.
For example: s sends A message and then sends B message, R can respond B message according to actual situation first, then respond A message, the message nesting and response disorder happen in the period, this and burst transmission have essential difference.
Further, the controlling the transmission type message may specifically include: parameter setting, parameter inquiry, state reporting, equipment control and response.
The control transmission category message is specifically referred to in the following table:
| binary value | Name(s) |
| 000001 | Parameter setting |
| 000010 | Parameter query |
| 000011 | State query |
| 000100 | Status reporting |
| 000101 | Device control |
| 111111 | Answering |
| Others | Retention |
Table 7 control transmission class message
Setting parameters: in general, when industrial control equipment needs to work normally, various environment parameters need to be set externally, and any process capable of changing the parameters is abstracted into parameter setting by the protocol;
parameter query: actively acquiring environmental information of current industrial control equipment;
and (3) state query: actively inquiring the state of the industrial control equipment, wherein the state is usually reported but delay may exist, so that active inquiry can be realized;
and (3) reporting the state: the device actively reports the current state information, and the general state belongs to the dynamic variables of the environment, and the current state information cannot be set like parameters, so the concept of 'state setting' does not exist. According to different application scenes, the state report can be timely reported or delayed, and under the latter condition, the external part can timely know the interested state through 'state query'.
Controlling equipment: and executing various control commands supported by the equipment, and paying attention to distinguishing and relation among 'control', 'parameter setting' and 'state inquiry'. If there is a "control" command that can only change the operating "parameters", then this "control" command should fall within the "parameter set" command category and not the "device control" subcategory.
And (3) response: if there is an answer in each sub-command, the answer sender uses the answer sub-command, so that the boundary between the command and the answer can be clearly distinguished from the protocol.
Example two:
as shown in fig. 2 and fig. 3, a controller based on an ICAP protocol provided in an embodiment of the present application includes a protocol header, and the controller may include a negotiation module 210, a definition module 220, and a processing module 230.
And the negotiation module 210 is configured to perform session negotiation with the terminal through the session type message, and establish a communication connection with the terminal according to a negotiation result.
Further, the session negotiation includes communication rate negotiation and communication security negotiation.
The communication rate negotiation comprises the maximum baud rate of a communication channel and the maximum data flux which can be borne by both communication parties; parameters for rate negotiation include: receive buffer and transmit buffer size.
The communication security negotiation comprises a session initiator informing a receiver of a supported symmetric encryption mode, wherein the encryption mode comprises DES,3DES, AES or NONE; wherein NONE indicates no encryption.
The first step of session establishment is session negotiation, and two communication parties need to carry out comprehensive negotiation on the characteristics of a communication channel to be established and can establish the communication channel after finally reaching an agreement.
The communication rate negotiation comprises the maximum baud rate of the communication channel and the maximum data flux which can be borne by the applications of the two communication parties. The channel baud rate does not need to be transmitted, the maximum baud rate is already determined after the connection mode is determined, and the parameter is known by both sides. The maximum data throughput that an application can tolerate by itself is typically related to the buffer size and the processing speed of the data in the buffer. Therefore, there are 2 parameters for rate negotiation, namely, the size of the receiving buffer and the sending buffer of both communication parties, and the endianness is from high to low:
| receiving buffer size | Transmit buffer size |
| 2bytes | 2bytes |
TABLE 1 Rate negotiation parameters Table
The communication security negotiation is a key step of confidentiality, and a session initiator informs a receiver of supported symmetric encryption modes including DES,3DES, AES and NONE. The full set is 4, and a subset of the support can be sent. The receiver selects one encryption mode according to self conditions, if NONE is selected, the encryption mode is not used, the message is transmitted in clear, and the characteristic can be only used in specific occasions, such as a research and development test stage, and the communication efficiency is improved in the occasions where one chip is difficult to monitor. This parameter is expressed in one byte, called the session option, and each of the 3-6 bits represents the support capability of an encryption scheme, as shown in the following table:
table 2 session option structure for rate negotiation parameters
If the session is established by the cube to force channel encryption, 0bit is set to 0, which indicates that communication without encryption is not supported, and the receiver cannot select a NON encryption mode, otherwise, the session cannot be established.
The idle window or heartbeat interval negotiation idle window refers to the measurement of communication activity, is the time of bus idle, and the session can be kept valid in the idle window all the time, and if the bus idle time exceeds the window time, the session can be invalid. The data consists of 4 bytes, 0 representing an infinitely long time window. The final result is based on the number of the response, if the sender gives a non-0 number, the receiver responds 0, and the sender has the right to refuse to continue the negotiation. When the flag in the session option selects the heartbeat interval, session maintenance will be based on the heartbeats, and the session will fail after a specified number of heartbeats have not been answered. And only selecting one of the idle window and the heartbeat interval, and maintaining the session by default by adopting the heartbeat. After the session is invalid, any received message is discarded without any response.
The defining module 220 is used for defining the information category and the transmission mode to be transmitted through the protocol header.
The protocol header may include the following fields:
the package attributes are: including a transmission mode, the transmission mode including a control transmission and a burst transmission;
command: command types are defined including session class messages, control transfer class messages, and burst transfer class messages.
The command field can be merged with the data field, i.e. the content of the command field can be stored in the data field. When the transport layer and network layer protocols communicate, the contents of the command field of the transport layer protocol or the network layer protocol may be contained in a data field whose meaning is specified by the application layer.
Further, in an embodiment, the protocol header may specifically include the following fields:
| sign (C) | Packet length | Protocol version | Package attributes | ID | Command | Data of | crc |
| 1byte | 2bytes | 1byte | 1byte | 1byte | 1byte | nbytes | 1byte |
| 0x80 | High,LOW | - | - | - | - | - | - |
TABLE 3 protocol header component structure
Marking: a fixed 0x80 indicates that a packet is started and the flag may not be used for short-range communications.
Packet length: 1-4 bytes, the entire packet length, including the packet header, data payload, crc, facilitates parsing packet integrity.
Protocol version: 0-1 byte, the upper 4 bits are primary version, the lower 4 bits are secondary version, at most 255 versions are supported, 0 is reserved. The protocol version is set in order to make the protocol itself extensible and compatible, and the processing of messages by the message sender must be kept consistent, which is based on the protocol version information. The protocol supports a maximum of 255 versions, with 0 reserved, starting at a minimum at 0.1, major versions 0-0x0F, minor versions 1-0x 0F. For example, version: 0.1, 1.3, 15.15, etc. In one embodiment, the protocol header may also not contain a protocol version field, such as a bluetooth BLE channel, whose single frame data length cannot exceed 20 bytes.
Further, in another embodiment, the protocol header may include the following fields: packet attributes, message ID, data, packet length, in this embodiment, the protocol header may not include the following fields: flags, protocol version, and command fields, such as bluetooth BLE channel.
The package attributes are: the parsing and nature of the packet is controlled. Packet attributes control the properties of the packet, such as parsing and interaction, and currently use 1 byte:
table 4 packet attribute field composition structure of protocol header
The three bit fields may be arbitrarily arranged in the byte, may be arranged adjacent to each other or at intervals, and may be arranged at the upper or lower position. In one embodiment, the lowest order 0 represents the transmission mode, 0 represents the control transmission, the order of the various control transmissions does not matter, and messages can be transmitted interspersed; 1 indicates a burst transfer, and the burst transfer surface needs to transfer a large amount of data at a time, and the period cannot be interrupted until the transfer is completed, and the control transfer or the next burst transfer cannot be started. Bits 1-2 indicate symmetric encryption, 00 indicates no encryption, 01 indicates DES encryption, 10 indicates 3DES encryption, and 11 indicates AES encryption, and generally, encryption is a result of negotiation between both parties during session establishment, and some encryption cannot be simply and fixedly used, which is a gospel to an attacker, and is more secure only by dynamically negotiating encryption. Bit 3 indicates whether the data is compressed, 0 indicates no compression, the original byte content is transmitted, and 1 indicates that the byte compression strategy is adopted.
ID: namely, the message ID, the upper 4 bits are the session ID, the lower 4 bits are the packet sequence number during the session, and the lower 4 bits automatically start from 0 when they reach 0x 0F. The message ID is 1-4 bytes long, and in one embodiment, the message ID is structured as follows:
| 7-4 | 3-0 |
| session ID | Intra-session message ID |
Table 5 message ID field composition structure of protocol header
During session establishment, bits 7-4 are always 0, after establishment, the session ID starts from 1, and after F is reached, the loop starts from 1, and the message ID rules are consistent, that is, the ID field does not have the condition of being equal to 0.
Command: 1 byte, with the upper 2 bits being the command type and the lower 6 bits being the subcommands. The command adopts 1 byte, the high 2bit is a type, and the low 6bit is a subclass, and the design is convenient for command classification, so that the logic is clearer. The command field includes the following:
| binary value | Name (R) |
| 00 | Session category messages |
| 01 | Controlling transmission class messages |
| 10 | Burst transfer class message |
| 11 | Retention |
TABLE 6 Command field content of protocol header
Message subclass all 1 indicates this type of message reply message, but command byte 0xFF reserved is an invalid message class, since the 7-6 bit value 11 is a reserved value and 0xFF cannot occur. The session category message any reply has a definite subcategory with the purpose of unambiguously identifying all steps of the session establishment procedure, rather than an ambiguous general reply.
Data: the payload varies from command to command.
And (c) crc: the exclusive or value of 1 byte full packet data (except for the crc itself).
The processing module 230 is configured to send a control transmission type message to the terminal through a control transmission mode when the transmission mode is control transmission.
Further, the processing module 230 may include a processing unit 231;
a transmitting unit 231 for transmitting a plurality of pieces of request information;
the receiving unit 232 is configured to receive corresponding response information sent by the terminal, and the request information and the response information may be transmitted out of order and in a nested manner.
For example: s sends A message and then sends B message, R can respond B message according to actual situation first, then respond A message, the message nesting and response disorder occur during the period, this and burst transmission have essential difference.
Further, the controlling the transmission type message may specifically include: parameter setting, parameter inquiry, state report, equipment control and response.
The correspondence between the content of the control transmission type message and the binary value is specifically referred to the following table:
| binary value | Name (R) |
| 000001 | Parameter setting |
| 000010 | Parameter query |
| 000011 | State query |
| 000100 | Status reporting |
| 000101 | Device control |
| 111111 | Answering |
| Others | Retention |
Table 7 control transmission class message
Setting parameters: in general, when industrial control equipment needs to work normally, various environment parameters need to be set externally, and any process capable of changing the parameters is abstracted into parameter setting by the protocol;
parameter query: actively acquiring environmental information of current industrial control equipment;
and (3) state query: actively inquiring the state of the industrial control equipment, wherein the state is usually reported but delay may exist, so that active inquiry can be realized;
and (3) reporting the state: the device actively reports the current state information, and the general state belongs to the dynamic variables of the environment, and the current state information cannot be set like parameters, so the concept of 'state setting' does not exist. The state reporting is different according to application scenes, the reporting can be timely carried out, and the reporting can be delayed, and under the latter condition, the external part can timely know the interested state through 'state query'.
Controlling equipment: and executing various control commands supported by the equipment, and paying attention to distinguishing and relation among 'control', 'parameter setting' and 'state inquiry'. If there is a "control" command that can only change the operating "parameters", then this "control" command should fall within the "parameter set" command category and not the "device control" subcategory.
And (3) response: if there is an answer in each sub-command, the answer sender uses the answer sub-command, so that the boundary between the command and the answer can be clearly distinguished from the protocol.
Example three:
an implementation manner of the ICAP-based information transmission apparatus provided in the embodiment of the present application includes a memory and a processor.
A memory for storing a program;
and the processor is used for executing the program stored in the memory to realize the method in the first embodiment.
Example four:
a computer readable storage medium having a program stored thereon, the program being executable by a processor to perform the method of the first embodiment.
Those skilled in the art will appreciate that all or part of the functions of the various methods in the above embodiments may be implemented by hardware, or may be implemented by computer programs. When all or part of the functions of the above embodiments are implemented by a computer program, the program may be stored in a computer-readable storage medium, and the storage medium may include: a read only memory, a random access memory, a magnetic disk, an optical disk, a hard disk, etc., and the program is executed by a computer to realize the above functions. For example, the program may be stored in a memory of the device, and when the program in the memory is executed by the processor, all or part of the functions described above may be implemented. In addition, when all or part of the functions in the above embodiments are implemented by a computer program, the program may be stored in a storage medium such as a controller, another computer, a magnetic disk, an optical disk, a flash disk, or a removable hard disk, and may be downloaded or copied to a memory of a local device, or may be version-updated in a system of the local device, and when the program in the memory is executed by a processor, all or part of the functions in the above embodiments may be implemented.
The present invention has been described in terms of specific examples, which are provided to aid understanding of the invention and are not intended to be limiting. Numerous simple deductions, modifications or substitutions may also be made by those skilled in the art in light of the present teachings.
Claims (10)
1. An information transmission method based on an ICAP protocol, wherein the protocol comprises a protocol header, the method comprising:
the control terminal and the terminal carry out session negotiation through the session type message and establish communication connection with the terminal according to a negotiation result;
the control end defines the type and the transmission mode of the information to be transmitted through the protocol header;
and when the transmission mode is control transmission, the control terminal sends a control transmission type message to the terminal in a control transmission mode.
2. The method of claim 1, wherein the protocol header comprises the following fields:
the package attributes are: including a transmission mode, the transmission mode including control transmissions and burst transmissions;
command: command types are defined including session class messages, control transfer class messages, and burst transfer class messages.
3. The method of claim 1, wherein the controlling end sends the control transmission category message to the terminal through a control transmission manner, comprising:
the plurality of request messages sent by the control terminal and the corresponding response messages sent by the terminal can be transmitted out of order and in a nested manner.
4. The method of claim 1, wherein the controlling the transmission type message specifically comprises: parameter setting, parameter inquiry, state reporting, equipment control and response.
5. A controller based on an ICAP protocol, the protocol including a protocol header, the controller comprising:
the negotiation module is used for carrying out session negotiation with the terminal through the session type message and establishing communication connection with the terminal according to a negotiation result;
the definition module is used for defining the information category and the transmission mode to be transmitted through the protocol header;
and the processing module is used for sending a control transmission type message to the terminal through a control transmission mode when the transmission mode is control transmission.
6. The controller of claim 5, wherein the protocol header comprises the following fields:
the package attributes are: including a transmission mode, the transmission mode including a control transmission and a burst transmission;
command: command types are defined including session class messages, control transfer class messages, and burst transfer class messages.
7. The controller of claim 5, wherein the processing module comprises:
a transmitting unit configured to transmit a plurality of pieces of request information;
and the receiving unit is used for receiving corresponding response information sent by the terminal, and the request information and the response information can be transmitted out of order and in a nested manner.
8. The controller according to claim 5, wherein the controlling the transmission type message specifically comprises: parameter setting, parameter inquiry, state reporting, equipment control and response.
9. An information transmission apparatus based on an ICAP protocol, comprising:
a memory for storing a program;
a processor for implementing the method of any one of claims 1-4 by executing a program stored by the memory.
10. A computer-readable storage medium, characterized in that the storage medium has stored thereon a program which is executable by a processor for implementing the method according to any one of claims 1-4.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202210445156.5A CN115052052A (en) | 2022-04-26 | 2022-04-26 | Information transmission method, device and controller based on ICAP (independent component analysis protocol) |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202210445156.5A CN115052052A (en) | 2022-04-26 | 2022-04-26 | Information transmission method, device and controller based on ICAP (independent component analysis protocol) |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN115052052A true CN115052052A (en) | 2022-09-13 |
Family
ID=83157550
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202210445156.5A Pending CN115052052A (en) | 2022-04-26 | 2022-04-26 | Information transmission method, device and controller based on ICAP (independent component analysis protocol) |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN115052052A (en) |
Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN1809070A (en) * | 2006-01-26 | 2006-07-26 | 华为技术有限公司 | Method of implementing resource control on access layer per VC in L2VPN |
| CN1984132A (en) * | 2005-12-12 | 2007-06-20 | 华为技术有限公司 | Method and terminal for processing session ability information |
| CN102457437A (en) * | 2010-10-21 | 2012-05-16 | 巴比禄股份有限公司 | Connecting apparatus and method for transmitting packets |
-
2022
- 2022-04-26 CN CN202210445156.5A patent/CN115052052A/en active Pending
Patent Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN1984132A (en) * | 2005-12-12 | 2007-06-20 | 华为技术有限公司 | Method and terminal for processing session ability information |
| CN1809070A (en) * | 2006-01-26 | 2006-07-26 | 华为技术有限公司 | Method of implementing resource control on access layer per VC in L2VPN |
| CN102457437A (en) * | 2010-10-21 | 2012-05-16 | 巴比禄股份有限公司 | Connecting apparatus and method for transmitting packets |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US7461164B2 (en) | Medium access control with software -and hardware- based components in a wireless network | |
| US8897209B2 (en) | Systems and methods for parallel communication with legacy WLAN receivers | |
| CN110831240B (en) | Base station and user equipment for early data transmission in random access procedure | |
| CN107113782A (en) | System and method for avoiding interference in digital communication | |
| WO2022068506A1 (en) | Data transmission method and apparatus | |
| CN111727613A (en) | Data transmission method and device | |
| WO2021203850A1 (en) | Negotiation method for operation mode, initiating end, receiving end, chip system, and medium | |
| CN110808948A (en) | Remote procedure calling method, device and system | |
| WO2022042235A1 (en) | Data packet sending method and apparatus, data packet processing method and apparatus, device, and data packet | |
| WO2021204091A1 (en) | Method and device for clearing buffer | |
| WO2021212514A1 (en) | Device-to-device based resource determination method, and device | |
| US20150289297A1 (en) | Packet Transmission Method and System, and Station | |
| US9699685B1 (en) | Battery life assisted scheduling | |
| CN115052052A (en) | Information transmission method, device and controller based on ICAP (independent component analysis protocol) | |
| WO2020177169A1 (en) | Communication method, apparatus and system | |
| WO2021159907A1 (en) | Information transmission method, base station and terminal | |
| CN115052051B (en) | Information processing method, system, controller and terminal based on ICAP protocol | |
| CN115052056A (en) | Industrial control communication method, device, equipment and storage medium | |
| CN111182517A (en) | CAN and Bluetooth data conversion system and data transmission method thereof | |
| WO2022024176A1 (en) | Base station and terminal | |
| CN113364869B (en) | Block chain message transmission method, equipment and storage medium | |
| CN115052050A (en) | Session negotiation method, device and controller based on ICAP | |
| WO2021227703A1 (en) | Transmission method, device, and storage medium | |
| CN101765193B (en) | Method for scheduling resource in EDCH, user terminal and communication system | |
| CN110224803B (en) | LoRa communication method for realizing beacon autonomous discovery |
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 |