CN110166485B - Protocol scheduling and using method and device - Google Patents
Protocol scheduling and using method and device Download PDFInfo
- Publication number
- CN110166485B CN110166485B CN201910515854.6A CN201910515854A CN110166485B CN 110166485 B CN110166485 B CN 110166485B CN 201910515854 A CN201910515854 A CN 201910515854A CN 110166485 B CN110166485 B CN 110166485B
- Authority
- CN
- China
- Prior art keywords
- interface
- protocol
- self
- sending
- interfaces
- 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
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/133—Protocols for remote procedure calls [RPC]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/08—Protocols for interworking; Protocol conversion
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
- Y02P—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN THE PRODUCTION OR PROCESSING OF GOODS
- Y02P90/00—Enabling technologies with a potential contribution to greenhouse gas [GHG] emissions mitigation
- Y02P90/02—Total factory control, e.g. smart factories, flexible manufacturing systems [FMS] or integrated manufacturing systems [IMS]
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Security & Cryptography (AREA)
- Computer And Data Communications (AREA)
Abstract
The invention provides a protocol scheduling method and device, wherein a graphical interface and a first self-packaging interface are pre-constructed, the first self-packaging interface comprises scheduling relation information among N first protocol interfaces, and N is more than or equal to 1; the graphic interface is realized based on a first environment, and the first self-packaging interface and the first protocol interface are realized based on a second environment; on the basis, the required interface parameters can be configured based on the graphical interface, and the required protocol interface can be called by calling the self-packaging interface. The invention realizes the graphical operation of protocol calling, greatly reduces the difficulty and error rate when using the protocol stack of the second environment, and reduces the requirement on the encoding capacity of practitioners.
Description
Technical Field
The invention belongs to the technical field of vehicle-mounted Ethernet, and particularly relates to a scheduling and using method and device of a protocol.
Background
With the development of the intelligent driving technology, the application of the ethernet technology, especially the middleware technology based on the ethernet, in the field of intelligent driving is increasing, wherein due to the characteristics of high performance, distribution, cross-platform and the like of the zeroMQ, the zeroMQ is made to stand out of the middleware technology, and is widely applied to the processes of research and development, testing and the like of intelligent driving.
In the traditional automobile field, if a user needs to use the ZeroMQ protocol stack in the development process of an intelligent driving control algorithm, the ZeroMQ protocol stack is generally scheduled and used by writing corresponding calling logic code according to the open source code of the ZeroMQ. However, the control algorithm for intelligent driving is usually developed based on Matlab Simulink, while the ZeroMQ protocol stack is implemented based on C + + language code, and Matlab and traditional C/C + + have corresponding differences in syntax (such as definition of pointers, data types, and the like), constraints, and the like, which results in that the ZeroMQ protocol stack is not very friendly to the application in the traditional automobile industry, and has the problems that the ZeroMQ protocol stack is complex to call in the using process, is prone to make errors, and has high requirements on encoding capability of practitioners.
Therefore, how to provide a solution for using a protocol stack implemented based on another environment (such as the above-mentioned C + + environment) in one environment (such as the above-mentioned Matlab environment) so as to make the use process of the protocol stack implemented based on the another environment simple and friendly becomes a technical problem to be solved at present.
Disclosure of Invention
In view of the above, an object of the present invention is to provide a method and an apparatus for scheduling and using a protocol, so as to solve the problems of complicated calling, high error liability, high requirement on encoding capability of a practitioner, and the like when a protocol stack based on another environment is used in one environment, so that a calling process of the protocol stack implemented based on the other environment is simplified and friendly.
Therefore, the invention discloses the following technical scheme:
a method of scheduling use of a protocol, comprising:
acquiring interface parameters configured on a graphical interface;
calling a first self-packaging interface according to a corresponding processing flow based on the interface parameter;
calling N first protocol interfaces corresponding to the first self-packaging interface based on the first self-packaging interface;
the graphical interface and the first self-packaging interface are constructed in advance, the first self-packaging interface comprises scheduling relations among the N first protocol interfaces, and N is an integer greater than or equal to 1;
the graphical interface is implemented based on a first environment, and the first self-encapsulating interface and the first protocol interface are implemented based on a second environment.
Preferably, the method further includes: the data transmission device comprises a sending interface used for sending data information and a receiving interface used for receiving the data information;
the number of the sending interfaces is at least one, and the sending interfaces are used for respectively sending message messages to the same or different ports;
the number of the receiving interfaces is at least one, and the receiving interfaces are used for respectively receiving the message messages transmitted by the same or different ports.
In the above method, preferably, the message is in a message format defined in advance according to a Json file format;
the message format comprises a message header and a message body, wherein the message header comprises one or more of a data bus type, a data transmission channel and a data type, and the message body comprises one or more of a timestamp of message forming time, a node name, a data transceiving type, an internet protocol address of a node, a port number of data transmission, a length of a data packet and payload information.
Preferably, the method further includes: the configuration interfaces correspond to the ports one by one;
the configuration interface is used for generating a port descriptor required by data information transmission; the port descriptor or the address information of the port descriptor is stored in a global memory so as to be shared by at least one sending interface with the same port requirement.
Preferably, in the method, the sending the message by the sending interface includes:
acquiring the port descriptor from a global memory, or acquiring address information of the port descriptor from the global memory and acquiring the port descriptor based on the address information;
and based on the port descriptor, sending the message to a required port by using a corresponding protocol.
Preferably, in the method, the obtaining address information of the port descriptor from the global memory includes:
obtaining the identification information of the required port descriptor;
acquiring address information of a port descriptor corresponding to the identification information from a global memory, wherein the data type of the address information is a first data type corresponding to the first environment;
converting the data type of the address information into a second data type, the second data type being a second data type corresponding to the second environment.
In the method, preferably, the first environment includes a Matlab environment, and the second environment includes a C + + environment.
A scheduled use device of a protocol, comprising:
the acquisition unit is used for acquiring interface parameters configured on the graphical interface;
the first calling unit is used for calling a first self-packaging interface according to a corresponding processing flow based on the interface parameter;
the second calling unit is used for calling N first protocol interfaces corresponding to the first self-sealing interface based on the first self-sealing interface;
the graphics interface and the first self-packaging interface are constructed in advance, the first self-packaging interface comprises scheduling relations among the N first protocol interfaces, and N is an integer greater than or equal to 1;
the graphical interface is implemented based on a first environment, and the first self-encapsulating interface and the first protocol interface are implemented based on a second environment.
Preferably, the above apparatus, wherein the graphic interface includes: the data transmission device comprises a sending interface used for sending data information and a receiving interface used for receiving the data information;
the number of the sending interfaces is at least one, and the sending interfaces are used for sending message messages to the same or different ports respectively;
the number of the receiving interfaces is at least one, and the receiving interfaces are used for respectively receiving the message messages transmitted by the same or different ports.
Preferably, in the above apparatus, the graphic interface further includes: the configuration interfaces correspond to the ports one by one;
the configuration interface is used for generating a port descriptor required by data information transmission; the port descriptor or the address information of the port descriptor is stored in a global memory so as to be shared by at least one sending interface with the same port requirement.
According to the scheme, the method and the device for scheduling and using the protocol pre-construct the graphic interface and the first self-packaging interface, wherein the constructed first self-packaging interface comprises scheduling relation information among N (integers greater than or equal to 1) first protocol interfaces; the graphic interface is realized based on a first environment, and the first self-packaging interface and the first protocol interface are realized based on a second environment; on the basis of the configuration, each interface parameter required can be configured based on the form of the graphical interface, and the calling of one or more protocol interfaces required is realized through the calling of the self-packaging interface. Therefore, the invention realizes the graphical operation of protocol calling, and the encapsulation of the complex scheduling relation information of each protocol interface in the preset protocol stack into the more concise self-sealing interface, so that the complex calling codes of each protocol interface of the original protocol stack of the second environment do not need to be written in the first environment, and only the more concise self-sealing interface is designed to call the codes, thereby greatly reducing the difficulty and error rate of the protocol stack use, reducing the coding capability requirement on practitioners, and enabling the use process of the protocol stack of the second environment to be more concise and friendly.
Drawings
In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the embodiments or the prior art will be briefly described below, it is obvious that the drawings in the following description are only embodiments of the present invention, and for those skilled in the art, other drawings can be obtained according to the provided drawings without creative efforts.
Fig. 1 is a flowchart of a method for scheduling a protocol according to an embodiment of the present invention;
fig. 2 is a schematic diagram of a call relationship between a sending interface, a self-encapsulating interface, and each protocol interface of a ZeroMQ protocol stack according to an embodiment of the present invention;
fig. 3 is a message format example of CAN message information suitable for the automobile industry according to an embodiment of the present invention;
FIG. 4(a) is a schematic diagram illustrating a port collision caused by multiple transmission interfaces simultaneously transmitting data to the same port;
fig. 4(b) is a schematic diagram illustrating that multiple sending interfaces send data to the same port simultaneously through a created configuration interface according to an embodiment of the present invention;
fig. 5 is a schematic diagram of an implementation flow of sending a message by a sending interface according to an embodiment of the present invention;
fig. 6 is a schematic diagram of the principle that the ZeroMQ protocol interface is called by the three types of graphics interfaces and the self-sealing interface according to the present invention, so as to use the ZeroMQ protocol;
fig. 7 is a schematic structural diagram of a scheduling device of a protocol according to an embodiment of the present invention.
Detailed Description
The technical solutions in the embodiments of the present invention will be clearly and completely described below with reference to the drawings in the embodiments of the present invention, and it is obvious that the described embodiments are only a part of the embodiments of the present invention, and not all of the embodiments. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present invention.
The invention provides a method and a device for scheduling and using a protocol, and aims to solve the problems that a protocol stack (such as a zeroMQ protocol stack realized based on a C + + environment and the like, wherein the protocol and a corresponding protocol interface included in the zeroMQ protocol stack are realized based on the C + + environment) is complex and easy to make an error in calling, the requirement on the encoding capacity of practitioners is high and the like when the protocol stack realized based on a second environment is used in a first environment (such as an MATLAB environment and the like) in the field of automobiles.
Referring to fig. 1, a flowchart of a method for scheduling and using a protocol according to an embodiment of the present invention is provided, in this embodiment, as shown in fig. 1, the method for scheduling and using a protocol includes the following processing procedures:
The present embodiment will mainly describe the scheme of the present invention by taking the scheduling use of a ZeroMQ protocol stack implemented based on a C + + environment in a Matlab environment (an environment commonly used for developing and developing a control algorithm for intelligent driving), where the ZeroMQ refers to a series of interfaces similar to Socket and is mainly used for data transmission.
In order to simplify and make friendly the use process of a protocol stack such as zeroMQ, the invention constructs a plurality of graphics interfaces S-Function facing the zeroMQ protocol stack in a corresponding software tool (such as Matlab Simulink) of a first environment such as Matlab environment in advance, corresponding to two types of data receiving (receiving) and sending (sending) when the zeroMQ protocol stack is used for transmitting data, wherein the graphics interfaces at least comprise the following two types:
1) transmission interface for transmitting data information (sffunc _ zmqTransmit)
The number of the sending interfaces is at least one, and the sending interfaces are used for sending message messages to the same or different ports respectively.
2) Receiving interface for receiving data information (sffunc _ zmqRcv)
The number of the receiving interfaces is at least one, and the receiving interfaces are used for respectively receiving the message messages transmitted by the same or different ports.
In a specific implementation, each type of graphic interface may be pre-constructed with one or more interfaces according to actual needs, and the sending interface and the receiving interface are respectively provided with a plurality of interface parameters for a user to configure when the user has a processing requirement for data information (such as a sending processing requirement or a receiving processing requirement for data information), where the interface parameters provided by the sending interface (sfunc _ zmqTransmit) and the receiving interface (sfunc _ zmqRcv) and the related description information and source information of the interface parameters may specifically refer to examples provided in table 1 below:
TABLE 1
When the user needs to use the corresponding graphical interface, the required graphical interface can be called based on the corresponding operation, and the called graphical interface can be the sending interface or the receiving interface.
After the required graphical interface is called, the user may further configure interface parameters on the called graphical interface according to actual requirements, and taking the called graphical interface as a sending interface as an example, the parameter values of each interface parameter in table 1, such as an IP (Internet Protocol) address, a port, a transmission timeout parameter, a message type, a channel, a message ID (Identity, Identity number), a message size, and the like, configured on the sending interface may be obtained, where the parameter value of each interface parameter may be specifically configured and obtained in a Json configuration file manner.
The obtained parameter value of each interface parameter may be used when performing transmission processing on the data information (e.g., sending the data information or receiving the data information).
The received data information may be vehicle data from a vehicle, the vehicle data may include, but is not limited to, a CAN data packet or an Ethernet data packet provided by each monitoring component (radar, camera, etc.) on the vehicle, and the transmitted data information may be result data obtained by performing relevant processing on the vehicle data by using a developed corresponding control algorithm.
102, calling a first self-packaging interface according to a corresponding processing flow based on the interface parameters; the graphic interface and the first self-packaging interface are constructed in advance, the first self-packaging interface comprises a scheduling relation among the N first protocol interfaces, and N is an integer greater than or equal to 1.
Specifically, the present application pre-constructs at least one self-sealing interface, each self-sealing interface comprising: scheduling relation information among at least one protocol interface of a predetermined protocol stack is preset, and each self-sealing interface is realized based on the second environment such as a C/C + + environment; the processing flow comprises a plurality of processing links, wherein at least one of the plurality of processing links needs to call a first self-sealing interface in a self-sealing interface which is constructed in advance; and the first self-packaging interface is a self-packaging interface which is processed to a corresponding link according to a corresponding processing flow based on the interface parameters and is required to be called by the link.
The first protocol interface is N protocol interfaces corresponding to the first self-packaging interface. The scheduling relationship information between the at least one first protocol interface may include, but is not limited to, reference relationship information and/or precedence execution order information between the N protocol interfaces corresponding to the first self-sealing interface. The processing flow may be a data sending processing flow or a data receiving processing flow, taking sending data as an example, and according to a constraint provided by Matlab, the data processing flow may include several processing links of resource configuration (mdlstuprauntimesureresources) at a graphic interface runtime, initialization (mdlStart), output sending (mdlOutputs) of data information, resource release (mdleceanruntimeresources) at a graphic interface runtime, and end (mdlsup).
At least one of the processing links needs to call a corresponding protocol in a ZeroQM protocol stack to implement the processing of the link, for example, a resource allocation (mdlsetutputtimeresources) link in the operation of the graphics Interface needs to call two protocol APIs (Application Programming Interface ) of mq protocol stack, i.e., init () (initialization) and zmq:: bind () (binding) to implement the processing required by the link; the output and transmission (mdlOutputs) link of the data information needs to call the protocol APIs of the zeroQM protocol stack, namely zmq:: poll () (timeout waiting), zmq:: encode _ header (), zmq:: encode _ data () (data encoding) and zmq:: send () (transmission), so as to realize the processing required by the link; the resource release (mdlCleanRuntimeResources) link of the graphic interface runtime needs to call mq:: close () (close) protocol API to realize the processing required by the link, and the like.
The control algorithm of intelligent driving is usually developed based on Matlab Simulink, while the ZeroMQ protocol is implemented based on C + + language code, and Matlab and traditional C/C + + have corresponding differences in syntax (such as definition of pointers, data types, and the like), constraints, and the like, which results in that the application of the ZeroMQ protocol stack in the traditional automobile industry is not very friendly. The concrete expression is as follows: on one hand, the API interface form (i.e. protocol interface) given by the ZeroMQ protocol stack does not necessarily facilitate the graphics interface S-Function call of Matlab; on the other hand, the graphics interface S-Function of Matlab may call multiple API interfaces of the ZeroMQ protocol stack, thereby making the call process cumbersome.
In addition, the S-Function as a graphic interface in Matlab environment not only requires a user to be familiar with the framework of the S-Function, but also has a plurality of limitations in terms of coding constraint and data type use, and does not need to modify the S-Function too much from the viewpoint of development easiness and maintainability, and based on the considerations in terms of the aspects, in order to make the protocol call of the zeroMQ protocol stack realized based on the C + + environment under the Matlab environment more convenient and concise, the invention provides a technical idea of further carrying out API self-encapsulation on the protocol interface of the zeroMQ protocol stack based on the C + + environment, and particularly based on the logical association among the protocol interfaces of the zeroMQ protocol stack, the protocol interfaces with strong association are encapsulated to form a self-encapsulation interface (self-encapsulation API), and scheduling relationship information such as reference relationship and/or sequence execution order among the protocol interfaces is embodied in the self-encapsulation interface, and finally obtaining a plurality of self-packaging interfaces respectively packaged with at least one protocol interface and scheduling relation information thereof. Specifically, for example, the protocol APIs of mdlsetuttupruntitimeresources and scheduling relationship information thereof, which are called by the resource configuration (mdlsetutputrescueresources) link during the operation of the graphics interface, may be encapsulated into a whole to obtain zmqServerOn () from the self-sealing interface, the protocol APIs of zmq: (poll ()), zmq: (encode _ header (), zmq: (encode _ data ()), and zmq: (encode ()) required by the output and transmission (mdletutput) link of the data information may be encapsulated into a whole to obtain zmqSend (), the protocol APIs of mqsread () required by the resource release (mclearnetimmeresources) link during the operation of the graphics interface may be encapsulated into a self-sealing interface zmofff () and the like.
On the basis of further packaging each protocol interface of the zeroMQ protocol stack into each self-packaging interface, when the graphic interface design of a sending interface (sffunc _ zmqTransmit), a receiving interface (sffunc _ zmqRcv) and the like is carried out in a Matlab environment, only the calling code of the corresponding self-packaging interface (realized based on a C + + environment) needs to be designed therein, and the complex calling code of each protocol interface (realized based on the C + + environment) of the zeroMQ protocol stack does not need to be designed any more; and no matter the zeroMQ protocol stack is modified or upgraded, only the self-protocol interface of the zeroMQ needs to be modified and/or the relevant code of the self-encapsulation interface needs to be modified, and the code of the graphics interface S-Function does not need to be modified, so that the advantage of further self-encapsulation of the protocol interface of the zeroMQ protocol stack is obvious.
Referring to the following table 2, table 2 shows self-encapsulation interfaces corresponding to the processing links of the sending interface (sffunc _ zmqTransmit), and protocol interfaces of the ZeroQM protocol stack encapsulated corresponding to the respective encapsulation interfaces:
TABLE 2
Specifically, when a processing link included in the processing flow needs to call a corresponding protocol interface of a protocol stack, such as a ZeroMQ protocol stack, the code is not written and modified directly in the calling process, but a first self-encapsulation interface corresponding to the needed protocol interface is called, taking the processing link as a resource configuration (mdlstuptrreimmense resources) link as an example, the zmqServerOn () self-encapsulation interface is called specifically when the processing link is executed, and similarly, if the corresponding link needing to call the self-encapsulation interface is an output transmission (mdletut) link of the data information, the zmqSend () self-encapsulation interface is called specifically when the processing link is executed, and if the link needing to call the self-encapsulation interface is a resource release (mdclearnetruinessources) link when the graphics interface is operated, the zmserverf self-encapsulation interface () is called specifically when the processing link is executed.
And 103, calling N first protocol interfaces corresponding to the first self-sealing interface based on the first self-sealing interface.
As shown in table 2 above, taking the first self-encapsulated interface as zmqServerOn () as an example, the first protocol interface includes two interfaces, which are zmq:: init () and zmq:: bind (), respectively.
The first self-encapsulation interface simultaneously comprises scheduling relationship information among N first protocol interfaces, a schematic diagram of calling relationship among a sending interface, a self-encapsulation interface and each protocol interface of a zeroMQ protocol stack shown in figure 2 is referred, calling of each corresponding first protocol interface in the first self-encapsulation interface to be called can be further realized by calling the first self-encapsulation interface to be called of the corresponding link, referring to table 2, taking the corresponding link as an output sending (mdOutputs) of the data information as an example, calling of the zmqSend () can further realize calling of several protocol interfaces zmq:: poll (), zmq:: code _ header (), zmq:: encode _ data (), zmq: send () of the zeroMQ protocol stack, and further realize calling of the several protocol interfaces based on calling of the several protocol interfaces to wait for timeout and header coding of the required file, Data encoding, data transmission, etc.
Taking the self-encapsulating interface zmqSend () shown in table 2 as an example, if the self-encapsulating interface is not used, when data transmission is performed by using a transmission interface (sffunc _ zmqTransmit), zmq: (poll () protocol interface) of the ZeroMQ protocol stack is necessarily called first, and then zmq: (encode _ header (), zmq: (encode _ data (), zmq: (send ()) and other protocol interfaces of the protocol stack are called in sequence to sequentially implement processes such as header file encoding, data transmission and the like, obviously, the calling of the protocol interfaces is complicated, the calling of the codes is correspondingly complicated, and in order to meet the characteristic of timeout waiting, an Event judgment logic code needs to be added to the graphics interface S-Function of Matlab, so that an additional code amount is involved, the protocol interfaces S-Function are called directly in the graphics interface S-Function of Matlab, and a header file of the graphics interface S-Function needs to be added to the additional protocol interfaces, the design of the whole calling process of the protocol interface by the graphic interface is complex, and the problems can be well solved after the self-packaging technology thought of the invention is adopted to carry out the self-packaging on each protocol interface of the protocol stack.
Based on the above solutions, this embodiment implements graphical operation of protocol invocation, and implements encapsulation of complex scheduling relationship information of each protocol interface in a predetermined protocol stack into a simpler self-encapsulated interface, so that it is not necessary to write complex invocation codes of each protocol interface of an original protocol stack of a second environment in a first environment, and only needs to design the invocation codes for a simpler self-sealing interface, thereby greatly reducing difficulty and error rate of using the protocol stack, reducing requirements on encoding capability of practitioners, and enabling a using process of the protocol stack of the second environment to be simpler and more friendly.
In an optional embodiment of the present invention, when the sending interface sends a message, the sending interface specifically packages data information to be sent into a message in a predefined format, and sends the message.
The zeroMQ protocol stack is a top-level protocol stack, and in order to ensure the universality of the zeroMQ protocol stack, the definition of a message is relatively abstract, the type of a specified data field is not defined, and the analysis mode and method of the zeroMQ protocol stack need to be defined by a user in practical application. Specifically, in practical application, a user only needs to define an IP address, a source port and a destination port of a message, so that data CAN be transmitted and received, and the specific service content of the data is not standardized.
CAN messages will typically contain the following attributes:
CAN _ Channel/CAN Channel: no standard;
CAN _ ID/CAN message ID: less than 3 bytes (CAN standard frame);
CAN _ MSG _ DLC/CAN message length: 1 byte;
data content of CAN _ DataPayload/CAN message: 1-8 bytes;
ethernet packets will typically contain the following attributes:
eth _ Channel/Eth Channel: no standard;
eth _ PDU _ ID/PDU packet ID: 4 bytes;
eth _ PDU _ Length/PDU message Length: 4 bytes;
eth _ PDU _ DataPayload/PDU data content: 0-1464 bytes.
From the above characteristics, abstracts are made and the ZeroMQ message format may be defined to include a message header and a message body.
Taking CAN message information common to the automotive industry as an example, each field of the ZeroMQ message in the Json file may be defined to include, but is not limited to, one or more of the following fields:
< NodeName >: a node name;
< NodeType >: sending or receiving;
< endPoint >: a node IP address;
< Port >: port number for data transmission;
< BusType >: a data bus type;
< Channel >: a channel for data transmission;
[ ID >: data type, CAN data or ethernet data;
< PayloadSize >: the length of the data packet;
< Payload >: payload information;
< TimeStamp >: a timestamp of the message formation time;
one or more of the fields < BusType >, < Channel > and < ID > may be designed in the message header, and the remaining fields, i.e., < NodeName >, < NodeType >, < Endpoint >, < Port >, < Payload >, and < TimeStamp >, may be designed in the message body, and referring to fig. 3, fig. 3 shows an example of a message format of the CAN message information applicable to the automotive industry defined by the present invention.
On the basis of the above format definition of the zeroMQ message, when the data information is processed, the self-sealing interface required to be called in the corresponding link is called to realize the calling of the corresponding protocol interface, the data information can be processed based on the corresponding protocol, such as delayed waiting, coding processing and the like, and finally the processing result is encapsulated into the message in the predefined format, and then the message is sent, for example, the result data obtained after the complete vehicle data is processed by using the corresponding control algorithm is sent from the current PC to the PC for testing and verifying the result data according to the predefined format, and the like.
In specific implementation, a Json configuration file (used for describing a zeroMQ message) CAN be manufactured, a graphics interface S-Function CAN be manufactured, a self-encapsulation interface is constructed aiming at a protocol interface of a protocol stack, and the like, and finally the protocol interface CAN be called by calling the self-encapsulation interface so as to process data, so that the message format of the zeroMQ CAN be better adapted to the requirements of a common communication data format (such as CAN/Ethernet PDU) in the traditional automobile industry.
In a practical application scenario, the number of the sending interfaces in the Matlab environment may be multiple, and further, there may be a case where multiple sending interfaces need to send data to the same port at the same time, as shown in fig. 4(a), sending interface S-function1 needs to send data Msg1 and data Msg2 to a port with IP address 1.2.3.4 and port number 1001, while sending interface S-function2 also needs to send data Msg3 and data Msg4 to a port with IP address 1.2.3.4 and port number 1001, however, limited by the resource sharing mechanism of the graphics interface S-function of Matlab, when sending data, one S-function creates a port for itself to see (a port descriptor, which is a C object, and needs to be used when sending data), another S-function cannot create the same port, and thus, when sending data to the same port at the same time, multiple sending interfaces need to send data at the same time, causing port conflicts.
To solve the problem, in an optional embodiment of the present invention, a configuration interface (sffunc _ zmqSetup) for generating a port descriptor required for data information transmission is further provided, that is, the pre-constructed graphics interface may further include the configuration interface, and the configuration interface is also provided with a plurality of configurable interface parameters, for example, the interface parameters of the configuration interface may include, but are not limited to, parameters such as node IP address, port, and the like, and referring to table 3 below, table 3 below provides interface parameters, description information, and source information of the configuration interface of the present embodiment and the two types of interfaces (sending interface, receiving interface) provided above:
TABLE 3
The number of the configuration interfaces is the same as the number of ports required by each transmission interface when transmitting data, taking the example of fig. 4(a) as an example, since the transmission interface S-function1 and the transmission interface S-function2 correspond to one port, thus, as shown in FIG. 4(b), a configuration interface may be created for S-functions 1, S-function2, the created configuration interface provides the functionality to create a port descriptor porthandle for the S-function1, S-function2, and can store the created porthandle or the address information of the created porthandle in the global memory of Matlab, since the porthandle created by the configuration interface or the address information of the created porthandle is stored in the global memory of Matlab, so that the deposited porthandle or the address information of the porthandle is visible to each sending interface as said S-function1 and S-function2, can be shared by the S-function1 and the S-function 2.
Specifically, the port descriptor PortHandle identification information may be defined as a character string composed of an IP address and a port number of a desired port, and on this basis, as shown in fig. 4(b), a write function, such as an mxSetData () function, may be further adopted to write the address information of the PortHandle or the PortHandle into a global memory (work space memory) of Matlab.
In an optional embodiment of the present invention, referring to the schematic implementation flow diagram of sending a message by a sending interface shown in fig. 5, the sending interface may specifically implement sending the message by the following processing procedures:
When data information needs to be sent to a certain port, if a message corresponding to processing result information of a control algorithm needs to be sent from a current PC to a port of another PC for testing and verifying the processing result by using a sending interface, a required port descriptor can be obtained from a Matlab global memory according to identification information of a required port, or required address information of the required port can be obtained from the Matlab global memory according to the identification information of the required port, and further the required port is obtained based on the address information, and on the basis, the message can be finally sent to the required port by using a corresponding protocol in a ZeroMQ protocol stack based on the port; wherein the identification information of the port descriptor may be, but is not limited to, a globally unique identification of the port descriptor.
It should be noted that the data type of the PortHandle address information stored in the Matlab global memory is a first data type suitable for the Matlab environment, and the obtained PortHandle address information is finally used by a corresponding protocol in the ZeroMQ protocol stack in the C + + environment, so that the data type of the PortHandle address information needs to be converted from the first data type matched with the Matlab environment to a second data type matched with the C + + environment and used by the ZeroMQ protocol.
Referring to fig. 6, fig. 6 shows a schematic diagram of making a call to a ZeroMQ protocol interface based on the above three types of graphics interfaces provided by the present invention and the self-encapsulated interface provided, so as to use the ZeroMQ protocol.
In this embodiment, a configuration interface for generating a port descriptor required for data information transmission is created, and the port descriptor created by the configuration interface or address information of the port descriptor is stored in the global memory of the Matlab, so that a problem of port collision when multiple sending interfaces need to send data to the same port at the same time in the Matlab environment is solved, and data can be effectively sent to the same port at the multiple sending interfaces in the Matlab environment.
Corresponding to the foregoing method for scheduling and using a protocol, an embodiment of the present invention further provides a device for scheduling and using a protocol, and with reference to a schematic structural diagram of the device for scheduling and using a protocol shown in fig. 7, the device may include:
an obtaining unit 701, configured to obtain an interface parameter configured on a graphical interface;
a first calling unit 702, configured to call a first self-packaging interface according to a corresponding processing flow based on the interface parameter;
a second calling unit 703, configured to call, based on the first self-sealing interface, N first protocol interfaces corresponding to the first self-sealing interface;
the graphics interface and the first self-packaging interface are constructed in advance, the first self-packaging interface comprises scheduling relations among the N first protocol interfaces, and N is an integer greater than or equal to 1;
the graphical interface is realized based on a first environment, and the first self-packaging interface and the first protocol interface are realized based on a second environment.
In an optional implementation manner of the embodiment of the present invention, the graphics interface includes: the data transmission device comprises a sending interface used for sending data information and a receiving interface used for receiving the data information; the number of the sending interfaces is at least one, and the sending interfaces are used for sending message messages to the same or different ports respectively; the number of the receiving interfaces is at least one, and the receiving interfaces are used for respectively receiving the message messages transmitted by the same or different ports.
In an optional implementation manner of the embodiment of the present invention, the message is in a message format defined in advance according to a Json file format;
the message format comprises a message header and a message body, wherein the message header comprises one or more of a data bus type, a data transmission channel and a data type, and the message body comprises one or more of a timestamp of message forming time, a node name, a data transceiving type, an internet protocol address of a node, a port number of data transmission, a length of a data packet and payload information.
In an optional implementation manner of the embodiment of the present invention, the graphics interface further includes: the configuration interfaces correspond to the ports one by one;
the configuration interface is used for generating a port descriptor required by data information transmission; the port descriptor or the address information of the port descriptor is stored in a global memory so as to be shared by at least one sending interface with the same port requirement.
In an optional implementation manner of the embodiment of the present invention, the sending interface sending a message includes:
acquiring a required port descriptor from a global memory, or acquiring address information of the required port descriptor from the global memory and acquiring the required port descriptor based on the address information;
and based on the port descriptor, sending the message to a required port by using a protocol corresponding to a corresponding protocol interface.
In an optional implementation manner of the embodiment of the present invention, the acquiring, by the sending interface, address information of a required port descriptor from a global memory includes:
obtaining identification information of the port descriptor;
acquiring address information of a port descriptor corresponding to the identification information from a global memory, wherein the data type of the address information is a first data type corresponding to the first environment;
converting the data type of the address information into a second data type, the second data type being a second data type corresponding to the second environment.
The scheduling and using device of the protocol disclosed in the embodiments of the present invention is relatively simple in description because it corresponds to the scheduling and using method of the protocol disclosed in each embodiment, and for the relevant similarities, please refer to the description of the scheduling and using method of the protocol in each embodiment, and detailed description is omitted here.
It should be noted that, in the present specification, the embodiments are all described in a progressive manner, each embodiment focuses on differences from other embodiments, and the same and similar parts among the embodiments may be referred to each other.
For convenience of description, the above system or apparatus is described as being divided into various modules or units by function, respectively. Of course, the functions of the units may be implemented in the same software and/or hardware or in a plurality of software and/or hardware when implementing the invention.
From the above description of the embodiments, it is clear to those skilled in the art that the present invention can be implemented by software plus necessary general hardware platform. Based on such understanding, the technical solutions of the present invention may be embodied in the form of a software product, which may be stored in a storage medium, such as ROM/RAM, magnetic disk, optical disk, etc., and includes instructions for causing a computer device (which may be a personal computer, a server, or a network device, etc.) to execute the method according to the embodiments or some parts of the embodiments.
Finally, it is further noted that, herein, relational terms such as first, second, third, fourth, and the like may be used solely to distinguish one entity or action from another entity or action without necessarily requiring or implying any actual such relationship or order between such entities or actions. Also, the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising an … …" does not exclude the presence of other identical elements in a process, method, article, or apparatus that comprises the element.
The foregoing is only a preferred embodiment of the present invention, and it should be noted that, for those skilled in the art, various modifications and decorations can be made without departing from the principle of the present invention, and these modifications and decorations should also be regarded as the protection scope of the present invention.
Claims (6)
1. A protocol scheduling and using method is applied to an application scene for developing, testing and verifying a control algorithm of intelligent driving based on collected vehicle data, and comprises the following steps:
acquiring interface parameters configured on a graphical interface facing a zeroMQ protocol stack;
based on the interface parameters, carrying out calling code design on a first self-sealing interface, and calling the first self-sealing interface according to a corresponding processing flow;
calling first protocol interfaces of N ZeroMQ protocol stacks corresponding to the first self-sealing interface based on the first self-sealing interface;
the graphics interface and the first self-packaging interface are constructed in advance, the first self-packaging interface corresponds to a processing link, the first self-packaging interface comprises first protocol interfaces of the N zeroMQ protocol stacks corresponding to the processing link and a scheduling relation between the first protocol interfaces of the N zeroMQ protocol stacks, and N is an integer greater than or equal to 1;
the graphical interface is implemented based on a first environment, and the first self-packaging interface and the first protocol interface are implemented based on a second environment;
the graphical interface includes: the system comprises a sending interface used for sending data information, a receiving interface used for receiving the data information and a configuration interface;
the number of the sending interfaces is at least one, and the sending interfaces are used for sending message messages to the same or different ports respectively;
the number of the receiving interfaces is at least one, and the receiving interfaces are used for respectively receiving message messages transmitted by the same or different ports;
the configuration interfaces correspond to the ports one to one;
the configuration interface is used for generating a port descriptor required by data information transmission; the port descriptor or the address information of the port descriptor is stored in a global memory so as to be shared by at least one sending interface with the same port requirement.
2. The method according to claim 1, wherein the message is in a message format defined in advance according to a Json file format;
the message format comprises a message header and a message body, wherein the message header comprises one or more of a data bus type, a data transmission channel and a data type, and the message body comprises one or more of a timestamp of message forming time, a node name, a data transceiving type, an Internet protocol address of a node, a port number of data transmission, a length of a data packet and payload information.
3. The method of claim 1, wherein sending the message by the sending interface comprises:
acquiring the port descriptor from a global memory, or acquiring address information of the port descriptor from the global memory and acquiring the port descriptor based on the address information;
and based on the port descriptor, sending the message to a required port by using a corresponding protocol.
4. The method of claim 3, wherein the obtaining the address information of the port descriptor from the global memory comprises:
obtaining identification information of the port descriptor;
acquiring address information of a port descriptor corresponding to the identification information from a global memory, wherein the data type of the address information is a first data type corresponding to the first environment;
converting the data type of the address information into a second data type, the second data type being a second data type corresponding to the second environment.
5. The method of claim 1 or 4, wherein the first environment comprises a Matlab environment and the second environment comprises a C + + environment.
6. The utility model provides a dispatch operative installations of agreement which characterized in that is applied to and carries out development, test and the application scene verified to the control algorithm of intelligent driving based on whole car data of collection, includes:
the acquisition unit is used for acquiring interface parameters configured on a graphics interface facing to a zeroMQ protocol stack;
the first calling unit is used for carrying out calling code design on the first self-sealing interface based on the interface parameters and calling the first self-sealing interface according to a corresponding processing flow;
the second calling unit is used for calling the first protocol interfaces of the N zeroMQ protocol stacks corresponding to the first self-sealing interface based on the first self-sealing interface;
the graphics interface and the first self-packaging interface are constructed in advance, the first self-packaging interface corresponds to a processing link, the first self-packaging interface comprises first protocol interfaces of the N zeroMQ protocol stacks corresponding to the processing link and a scheduling relation between the first protocol interfaces of the N zeroMQ protocol stacks, and N is an integer greater than or equal to 1;
the graphical interface is implemented based on a first environment, and the first self-packaging interface and the first protocol interface are implemented based on a second environment;
the graphical interface includes: a sending interface used for sending data information and a receiving interface used for receiving the data information, and a configuration interface;
the number of the sending interfaces is at least one, and the sending interfaces are used for sending message messages to the same or different ports respectively;
the number of the receiving interfaces is at least one, and the receiving interfaces are used for respectively receiving message messages transmitted by the same or different ports;
the configuration interfaces correspond to the ports one to one;
the configuration interface is used for generating a port descriptor required by data information transmission; the port descriptor or the address information of the port descriptor is stored in a global memory so as to be shared by at least one sending interface with the same port requirement.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201910515854.6A CN110166485B (en) | 2019-06-14 | 2019-06-14 | Protocol scheduling and using method and device |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201910515854.6A CN110166485B (en) | 2019-06-14 | 2019-06-14 | Protocol scheduling and using method and device |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN110166485A CN110166485A (en) | 2019-08-23 |
| CN110166485B true CN110166485B (en) | 2022-07-08 |
Family
ID=67625207
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201910515854.6A Active CN110166485B (en) | 2019-06-14 | 2019-06-14 | Protocol scheduling and using method and device |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN110166485B (en) |
Families Citing this family (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN111711940B (en) * | 2020-04-29 | 2023-10-31 | 杭州涂鸦信息技术有限公司 | Intelligent device data interaction method, intelligent device and storage device |
| CN112202798B (en) * | 2020-10-09 | 2022-07-15 | 平安科技（深圳）有限公司 | Data protocol conversion method, system, electronic device and storage medium |
| CN112532492A (en) * | 2020-12-08 | 2021-03-19 | 航天科技控股集团股份有限公司 | CAN virtual message construction method and system for testing automobile instrument |
Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN1471267A (en) * | 2002-07-22 | 2004-01-28 | 华为技术有限公司 | Network protocol measuring method and measuring system thereof |
| CN103729292A (en) * | 2013-12-30 | 2014-04-16 | 瑞达信息安全产业股份有限公司 | Cross-host cross-platform remote command invoking method and system |
| CN103809983A (en) * | 2014-02-27 | 2014-05-21 | 山东超越数控电子有限公司 | Method for modifying BIOS SETUP interface |
| CN104994122A (en) * | 2015-05-12 | 2015-10-21 | 深圳市微阳信息技术有限公司 | Business communication method and system based on JSON data protocol |
| CN105900063A (en) * | 2014-06-26 | 2016-08-24 | 郑基雄 | Method for scheduling in multiprocessing environment and device therefor |
Family Cites Families (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20180059976A1 (en) * | 2016-08-26 | 2018-03-01 | Sandisk Technologies Llc | Storage System with Integrated Components and Method for Use Therewith |
| CN109976834B (en) * | 2019-03-29 | 2022-01-28 | 上海仁童电子科技有限公司 | Protocol stack parameter configuration method and device |
-
2019
- 2019-06-14 CN CN201910515854.6A patent/CN110166485B/en active Active
Patent Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN1471267A (en) * | 2002-07-22 | 2004-01-28 | 华为技术有限公司 | Network protocol measuring method and measuring system thereof |
| CN103729292A (en) * | 2013-12-30 | 2014-04-16 | 瑞达信息安全产业股份有限公司 | Cross-host cross-platform remote command invoking method and system |
| CN103809983A (en) * | 2014-02-27 | 2014-05-21 | 山东超越数控电子有限公司 | Method for modifying BIOS SETUP interface |
| CN105900063A (en) * | 2014-06-26 | 2016-08-24 | 郑基雄 | Method for scheduling in multiprocessing environment and device therefor |
| CN104994122A (en) * | 2015-05-12 | 2015-10-21 | 深圳市微阳信息技术有限公司 | Business communication method and system based on JSON data protocol |
Non-Patent Citations (1)
| Title |
|---|
| "Galaxie平台分布式节点通信管理模块的设计与实现";沈忱;《中国优秀硕士学位论文全文数据库信息科技辑》;20150831;全文 * |
Also Published As
| Publication number | Publication date |
|---|---|
| CN110166485A (en) | 2019-08-23 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN110166485B (en) | Protocol scheduling and using method and device | |
| CN108521343B (en) | OAM message processing method and device | |
| CN102810069A (en) | JAVA object requesting and responding methods, devices and systems and terminal | |
| CN108322437B (en) | Adaptive communication method and device for multiple protocol devices | |
| US10303529B2 (en) | Protocol for communication of data structures | |
| CN103777950B (en) | Gridding method for resolving AOS (Advanced Orbiting System) telemetering data | |
| US20180262560A1 (en) | Method and system for transmitting communication data | |
| CN114157692A (en) | Multi-source polymorphic mass heterogeneous terminal universal access interconnection protocol conversion method and system | |
| CN206922798U (en) | A kind of Multi-protocol converter, data transmitting equipment and communication system | |
| CN113609059B (en) | Communication system and communication method | |
| MXPA05010962A (en) | Method of managing communication buffers employing an application framework for a plurality of communication layers and node employing the same. | |
| CN108810000B (en) | Method and device for generating serialization and deserialization API | |
| CN113296979B (en) | Data communication method for unreal engine and external program | |
| CN112769700B (en) | Routing method and routing system based on application method number | |
| CN114095584A (en) | Model conversion and construction method of industrial equipment data and readable storage medium | |
| CN113037834A (en) | Web page state updating method and device based on distributed instant push | |
| CN107623555B (en) | Method and device for realizing universal communication simulation platform | |
| CN106911546A (en) | A kind of message transmitting method, device, system and diagnostic platform | |
| CN108521416B (en) | ECN integrated circuit board | |
| CN106302432A (en) | A kind of communicator based on car networking and control method | |
| Oh et al. | CORBA based core middleware architecture supporting seamless interoperability between standard home network middlewares | |
| CN110430110B (en) | On-site bus gateway and protocol conversion method thereof | |
| CN109582481B (en) | Transmission method, device and equipment of call result and storage medium | |
| CN103118023B (en) | A kind of method and system of the data of transmission specification in a network | |
| CN113973105A (en) | System and method for simplifying SOAP message on service bus |
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 | ||
| CB02 | Change of applicant information |
Address after: 4 / F, building 1, No.14 Jiuxianqiao Road, Chaoyang District, Beijing 100020 Applicant after: Beijing Jingwei Hengrun Technology Co.,Ltd. Address before: 8 / F, block B, No. 11, Anxiang Beili, Chaoyang District, Beijing 100101 Applicant before: Beijing Jingwei HiRain Technologies Co.,Ltd. |
|
| CB02 | Change of applicant information | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |