Data transmission method, device, equipment and medium

Abstract

The embodiment of the invention provides a data transmission method and device, equipment and a medium, and relates to the technical field of embedded software. The method comprises the following steps: connecting a server with a client through a data distribution service DDS; and when the data writer is used for writing the service data into the DDS, mapping the service data to the theme of the corresponding DDS by using the event, the method and the field defined in the service interface, so that the data reader reads the service data by reading the theme of the DDS. Therefore, service data can be transmitted through the DDS protocol, data sharing of QoS control is provided, communication between application programs is achieved through a publishing and subscribing mechanism, and the method has the advantages of being efficient, real-time and reliable.

Description

Technical Field

[0001] The present application relates to the field of embedded software technology, and in particular to a data transmission method, device, equipment and medium. Background Art

[0002] With the rapid development of the automotive industry, especially the advancement of the new four modernizations, namely networking, autonomous driving, electrification and data-driven, the automotive industry's demand for software architecture is becoming increasingly complex. The core idea of ​​service-oriented architecture (SOA) is to divide the different functions of an application into independent services, which communicate with each other through well-defined interfaces, thus bringing flexibility and scalability to the automotive industry.

[0003] At present, the underlying communication details of the SOA software architecture in the automotive industry are usually implemented using the SOME / IP protocol. The SOME / IP protocol uses a server-client service form for communication, making the service highly scalable. However, in the face of the growing demand for data transmission and high requirements for quality of service (QoS), the SOME / IP protocol is still insufficient in processing complex data and providing diversified services. The Data Distribution Service (DDS) communication method is data-centric, provides QoS-controlled data sharing, and realizes communication between applications through a publish and subscribe mechanism, which is efficient, real-time and reliable.

[0004] However, the DDS communication method does not directly support service interfaces, which to some extent limits its application in service-centric architectures. Summary of the invention

[0005] Based on the above problems, the present application provides a data transmission method, device, equipment and medium, which can be transmitted through the DDS protocol and have the characteristics of high efficiency, real-time and reliability.

[0006] The embodiments of the present application disclose the following technical solutions:

[0007] In a first aspect, the present application provides a data transmission method, which is applied to a server, and the method includes:

[0008] Connecting the server and the client via a data distribution service DDS;

[0009] When the service data is written into the DDS using a data writer, the service data is mapped to the corresponding subject of the DDS using the events, methods and fields defined in the service interface, so that the data reader can read the service data by reading the subject of the DDS.

[0010] Optionally, mapping the service data to the corresponding subject of the DDS by using the method defined in the service interface so that a data reader reads the service data by reading the subject of the DDS includes:

[0011] Using the method defined in the service interface, create a reply topic;

[0012] The method to be published is mapped to the request subject through the data writer in the server, so that the data reader reads the service data by reading the reply subject.

[0013] Optionally, mapping the service data to the corresponding subject of the DDS by using the fields defined in the service interface so that a data reader reads the service data by reading the subject of the DDS includes:

[0014] Obtaining a target attribute in the field, wherein the target attribute is used to determine an event type corresponding to the field;

[0015] When the target attribute indicates that the event type corresponding to the field is a first type event, according to the to-be-published fields defined in the service interface and the data structure of the to-be-published fields, a target DDS topic matching the first type event is created by a preset naming rule; and the service data is mapped to the target DDS topic by using the to-be-published fields;

[0016] When the target attribute indicates that the event type corresponding to the field is a second type event, a reply subject is created using the fields defined in the service interface; the fields to be published are mapped to the request subject through a data writer, so that a data reader can read the service data by reading the reply subject.

[0017] Optionally, the method further comprises:

[0018] If the definition item in the service interface is an event or a field of a first value, configuring the service quality of the DDS;

[0019] If the definition item in the service interface is a method or a field of the second value, after the reliability service quality of the DDS is confirmed to be reliable, the persistence service quality is confirmed to be volatile, and the history service quality is confirmed to be fully retained, the remaining service qualities are configured.

[0020] Optionally, before executing the step of mapping the service data to the corresponding subject of the DDS by using the events, methods and fields defined in the service interface when writing the service data to the DDS using the data writer, the method further comprises:

[0021] A corresponding DDS topic is allocated to each to-be-published event defined in the service interface, and a data reader and a data writer are allocated to each of the DDS topics.

[0022] In a second aspect, the present application discloses a data transmission device, the device comprising: a connection module and a mapping module;

[0023] The connection module is used to connect the server and the client through the data distribution service DDS;

[0024] The mapping module is used to map the service data to the corresponding subject of the DDS by using the events, methods and fields defined in the service interface when the service data is written into the DDS by using the data writer, so that the data reader can read the service data by reading the subject of the DDS.

[0025] Optionally, the mapping module specifically includes: a first submodule and a second submodule;

[0026] The first submodule is used to create a reply topic using the method defined in the service interface;

[0027] The second submodule is used to map the method to be published to the request subject through the data writer in the server, so that the data reader reads the service data by reading the reply subject.

[0028] Optionally, the mapping module specifically includes: a third submodule, a fourth submodule and a fifth submodule;

[0029] The third submodule is used to obtain a target attribute in the field, where the target attribute is used to determine the event type corresponding to the field;

[0030] The fourth submodule is used for, when the target attribute indicates that the event type corresponding to the field is a first type of event, creating a target DDS topic matching the first type of event according to the to-be-published fields defined in the service interface and the data structure of the to-be-published fields by a preset naming rule; and mapping the service data to the target DDS topic by using the to-be-published fields;

[0031] The fifth submodule is used to create a reply subject using the fields defined in the service interface when the target attribute indicates that the event type corresponding to the field is a second type of event; and map the fields to be published to the request subject through a data writer, so that the data reader reads the service data by reading the reply subject.

[0032] Optionally, the device further includes: a first configuration module and a second configuration module;

[0033] The first configuration module is used to configure the service quality of the DDS if the definition item in the service interface is an event or a field of a first value;

[0034] The second configuration module is used to configure the remaining service qualities after the reliability service quality of the DDS is confirmed as reliable, the persistence service quality is confirmed as volatile, and the historical service quality is confirmed as fully retained if the definition item in the service interface is a method or a field of the second value.

[0035] Optionally, the device further comprises: a distribution module;

[0036] The allocation module is used to allocate a corresponding DDS topic to each to-be-published event defined in the service interface, and to allocate a data reader and a data writer to each of the DDS topics.

[0037] Compared with the prior art, this application has the following beneficial effects:

[0038] The embodiment of the present application provides a data transmission method, device, equipment and medium, the method comprising: connecting the server and the client through the data distribution service DDS; when using the data writer to write the service data to the DDS, using the events, methods and fields defined in the service interface, the service data is mapped to the corresponding DDS topic, so that the data reader can read the service data by reading the DDS topic. Thus, the service data can be transmitted through the DDS protocol, providing QoS controlled data sharing, realizing communication between applications through the publish and subscribe mechanism, and having the characteristics of high efficiency, real-time and reliability. BRIEF DESCRIPTION OF THE DRAWINGS

[0039] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative labor.

[0040] Figure 1A A schematic diagram of a server and a client provided in an embodiment of the present application;

[0041] Figure 1B A flowchart of a data transmission method provided in an embodiment of the present application;

[0042] Figure 2 A schematic diagram of mapping an event to a DDS Topic provided in an embodiment of the present application;

[0043] Figure 3 A mapping diagram of multiple service instances provided in an embodiment of the present application;

[0044] Figure 4 A schematic diagram of mapping a method provided in an embodiment of the present application to a DDS Topic;

[0045] Figure 5 A schematic diagram of a data transmission device provided in an embodiment of the present application;

[0046] Figure 6 A structural diagram of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0047] First, the technical terms involved in this application are explained:

[0048] Data Distribution Service (DDS) is a data-centric middleware protocol and API standard released by the Object Management Group. It adopts a distributed publish / subscribe architecture to provide communication services for applications and emphasizes data-centricity. As a software layer, DDS middleware abstracts the details of the operating system, network transmission, and underlying data format, allowing applications to exchange information between different operating systems, programming languages, and processing architectures. The Topic in DDS is the smallest unit of data publishing, similar to the queue in a message queue. The publisher writes data to a specific Topic, and the subscriber receives the data by subscribing to the corresponding Topic.

[0049] As described above, the underlying communication details of the current SOA software architecture in the automotive industry are usually implemented using the SOME / IP protocol based on the proxy-skeleton model. The SOME / IP protocol uses the Server-Client service form for communication, making the service highly scalable. As an application layer protocol, SOME / IP runs above the vehicle Ethernet transport layer and is responsible for implementing data interaction between the application layer and the IP layer. The advantage of the SOME / IP protocol lies in its maturity and completeness, providing a stable and reliable communication solution for the automotive industry.

[0050] Although the SOME / IP protocol has been widely used in the automotive industry, it is not good enough in terms of quality of service (QoS). As the internal systems of automobiles become increasingly complex and diverse, higher requirements are placed on the real-time, high efficiency and flexibility of data transmission. The SOME / IP protocol may have bottlenecks in ensuring real-time data distribution and efficient processing, and may not be able to meet the requirements of the increasingly complex and diverse internal systems of automobiles for real-time, high efficiency and flexibility of data transmission.

[0051] The DDS communication method is data-centric, provides QoS-controlled data sharing, and implements communication between applications through a publish and subscribe mechanism. It is efficient, real-time, and reliable.

[0052] However, the DDS communication method does not directly support service interfaces, which to some extent limits its application in service-centric architectures.

[0053] After research, the inventor proposed a data transmission method, device, equipment and medium, which includes: connecting the server and the client through the data distribution service DDS; when using the data writer to write the service data to the DDS, the service data is mapped to the corresponding DDS topic using the events, methods and fields defined in the service interface, so that the data reader can read the service data by reading the DDS topic. As a result, the service data can be transmitted through the DDS protocol, providing QoS controlled data sharing, and realizing communication between applications through the publish and subscribe mechanism, which has the characteristics of high efficiency, real-time and reliability.

[0054] In order to enable those skilled in the art to better understand the solution of the present application, the technical solution in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of this application.

[0055] See also Figure 1A , which is a schematic diagram of a server and a client provided in an embodiment of the present application. Among them, the server 10 (Server) represents the service provider, that is, the server 10 is responsible for providing services. The client 20 (Client) represents the service user, that is, the client 20 is responsible for requesting and using these services.

[0056] See also Figure 1B , which is a flowchart of a data transmission method provided in an embodiment of the present application.

[0057] The method includes:

[0058] S101: By allocating endpoints in DDS to the server and the client, the client and the server perform service discovery, and the client and the server perform connection.

[0059] Performing the service discovery process is the basis for communication between the server and the client. The following steps need to be performed after allocating endpoints in DDS to the server and client processes.

[0060] First, after the server is started, it will first encode the service information it provides in a predetermined format. The service information includes the service name, version, instance ID, address, port, provided interface and function description. The format of the above encoded service information can be as follows: "services: / / <svcid> <svcinid> - <svcmajversion> . <svcminversion> [& <svcid> <svcinid> - <svcmajversion> . <svcminversion>]*”.

[0061] Secondly, the server registers the encoded service information into the service discovery mechanism, so that the registration discovery mechanism further publishes the service information into DDS, so that the service information can be discovered by the client.

[0062] Afterwards, the server enters the waiting state while listening to the connection requests and interactions in DDS. Once a client requests a connection or interaction, the server will respond to these requests.

[0063] After the client is started, it will search for the required service in the service discovery mechanism through the DDS built-in endpoint. In some specific implementations, the service search and discovery can be performed through the DDS built-in protocols, such as the Service Provider Discovery Protocol (SPDP) and / or the Service Endpoint Discovery Protocol (SEDP).

[0064] Once the client finds the required service, it will obtain detailed service information, establish a connection with the server based on the service information, and start service interaction. Exemplarily, the service interaction between the server and the client may include calling an interface provided by the server, transmitting data, receiving a response, etc.

[0065] It should be noted that the server can stop publishing its service information in service discovery at any time (for example, when the server is restarted or shut down). When the server stops publishing the service information it provides in service discovery, the client will detect that the server has stopped publishing the service information. Subsequently, the client will unmatch with the server and stop communicating with the server. And, if the client still needs the service, it may re-initiate the service search process to find other available servers.

[0066] S102: Map the events, methods, and fields in the service interfaces in the server and client to the DDS Topic.

[0067] The communication between the server and the client usually relies on specific data channels, which are defined by DDS Topics. When it comes to different types of interface types in the service interface (including events, methods, and fields), each interface type needs to be mapped to the corresponding DDS Topic for data transmission.

[0068] First, the method of mapping events in the service interface to DDS Topic is explained:

[0069] See also Figure 2 , which is a schematic diagram of the mapping between an event and a DDS Topic provided in an embodiment of the present application. Each event in the service interface needs to correspond to a DDC Topic, and a corresponding data reader (DataReader) and data writer (DataWriter) must be allocated to each DDC Topic, so that data can be read and written on the client and server respectively.

[0070] When mapping events to DDS Topics, you need to follow a specific naming convention, namely "ServiceName+EventTypeName+EventTopic". In this way, each event can clearly know which DDS topic it corresponds to. For example, if the service name is "MyService" and the event type is "MyEvent", the DDS Topic name may be "MyServiceMyEventEventTopic".

[0071] When the event is published in the server, the server writes the event data into the DDS Topic through the data writer corresponding to the DDS Topic. The client can directly find and locate the required DDSTopic based on the known naming rules, and then read the event data through the data reader corresponding to the DDS Topic and perform subsequent processing as needed.

[0072] See also Figure 3 , which is a mapping diagram of multiple service instances provided in an embodiment of the present application.

[0073] There is a special type of DDS Topic called WithKey. This type of topic has a @key field to identify the instance ID of each service instance. This means that different events of the same service will be mapped to different topics in DDS. Even if it is the same event, if it is in different service instances, they will correspond to different instances of the same DDSTopic.

[0074] In DDS, the structure of data is defined by the Interface Definition Language (IDL). For each event-mapped DDS Topic, its IDL definition includes a @key field, which is a 16-bit unsigned integer representing the ID of the service instance, and a data field, which represents the actual data content of the event. An IDL can be as follows:

[0075] struct <servicename> <eventtypename>EventTopic{

[0076] @keyunit16 service_instance_id;

[0077] <eventtypename>data;

[0078] };

[0079] Among them, service_instance_id is a key field (indicated by the @key tag) used to distinguish different instances of the same service. Each service instance should have a unique service_instance_id so that DDS can know which service instance different events come from. data is the actual data of the event, and its type is determined by <eventtypename>Specified. This field contains the specific information of the event. That is, when using a keyed DDS Topic, DDS will distinguish different instances based on the value of service_instance_id. Even if two events have the same data content, as long as their service_instance_id is different, they will be considered to be published to different instances.

[0080] Since data readers and data writers send and receive data according to DDS Topics instead of distinguishing them according to service instances, data confusion may occur when there are multiple data readers and data writers corresponding to multiple service instances. To solve this problem, a pair of data readers and data writers needs to be instantiated for each service instance. In this way, each pair of data readers and data writers is only responsible for sending and receiving data for a specific event topic under a service instance.

[0081] To ensure that data between different instances is not mixed, we use Partition QoS to separate them. The setting rule of Partition QoS is "service: / / service_id-instance_id". In this way, the data of each service instance will be correctly sent to the corresponding data reader and read from the corresponding data writer, thus avoiding the problem of data confusion.

[0082] Next, the method of mapping the service interface method to the DDS Topic is explained:

[0083] See also Figure 4 , which is a schematic diagram of the mapping between a field and a DDS Topic provided in an embodiment of the present application. According to the Data Distribution Service-Remote Procedure Call (DDS-RPC) specification, each method in the service interface will be aggregated together and mapped to a pair of request topics (Request Topic) and reply topics (Reply Topic). Each topic will be assigned a pair of data readers and data writers to perform data reading and writing operations.

[0084] For the server 10 , it has a data reader associated with the request topic for receiving request data from the client 20 , and it also has a data writer associated with the reply topic for sending response data back to the client 20 .

[0085] For the client 20 , it uses the data writer associated with the request topic to send request data to the server 10 , and it also uses the data reader associated with the reply topic to receive response data from the server 10 .

[0086] It should be noted that the naming rule for request topics is "ServiceName+Method+RequestTopic" and the naming rule for reply topics is "ServiceName+Method+ReplyTopic", which ensures the uniqueness of RequestTopic and ReplyTopic. By combining the service name (ServiceName), method name (Method) and a fixed suffix (RequestTopic or ReplyTopic) to construct a topic name, it helps to clearly identify and manage different RPC communication channels in the DDS system.

[0087] It should be noted that since there may be multiple methods in a service interface, all method requests (Invoke) and response data (Return) are collected in a pair of DDS Topics. Therefore, the server 10 needs to parse which method this DDS Topic data belongs to. Therefore, all method data needs to be aggregated into UnionType. According to the serialization method of Union Type in the DDS-XTYPES specification, a 32-bit signed integer discriminator is sent before the actual data to identify the specific method. This discriminator is calculated based on the Method name using the MD5 algorithm.

[0088] It should be noted that, unlike the above events, the Topic of method mapping is keyless (NoKey), which means that in DDS, the Topic used for Method calls does not rely on specific keys to distinguish data. The Methods of different service instances also need to be distinguished. According to the DDS-RPC specification, the instance_id of the service instance can be mapped to the InstanceName field of the RequestHeader and ReplyHeader to identify which service instance this message belongs to. The DataReader and DataWriter under different service instances are also separated by Partition QoS. The Partition QoS setting rules are consistent with the Event mapping, which is "service: / / service_id-instance_id". The IDL definitions of RequestTopic and ReplyTopic are as follows:

[0089] struct <servicename>MethodRequestTopic{

[0090] dds::rpc::RequestHeaderheader;

[0091] <servicename>MethodCall union_data;

[0092] };

[0093] struct <servicename>MethodReplyTopic{

[0094] dds::rpc::ReplyHeaderheader;

[0095] <servicename>MethodReturnunion_data;

[0096] };

[0097] Then, the method of mapping the fields in the service to the DDS Topic is explained:

[0098] In one example, when the hasNotifier property of a field in the service interface is True, this field can be regarded as an event. That is to say, each field in the service must correspond to a DDS Topic, and a corresponding data reader and data writer must be assigned to each DDS Topic to read and write data on the client 20 and the server 10, respectively. Exemplarily, the naming rule of the DDS Topic Name corresponding to the field is: "ServiceName+FieldTypeName+NotifierTopic", and the corresponding IDL definition is as follows:

[0099] struct <servicename> <fieldtypename>NotifierTopic{

[0100] @key unit16 service_instance_id;

[0101] <fieldtypename>data;

[0102] };

[0103] In another example, when the hasGetter or hasSetter property of a field in a service interface is True, the field can be considered as a method. That is, each field in a service interface must be aggregated and mapped to a pair of request topics and reply topics, and each DDS Topic is assigned a pair of data readers and data writers to read and write data.

[0104] For the server 10, it has a data reader associated with the request topic for receiving request data from the client 20, and it also has a data writer associated with the reply topic for sending response data back to the client 20. For the client 20, it uses the data writer associated with the request topic to send request data to the server 10, and it also uses the data reader associated with the reply topic to receive response data from the server 10. The naming rule of the request topic to which the field is mapped is "ServiceName+Field+RequestTopic", and the naming rule of the reply topic is "ServiceName+Field+ReplyTopic", and the corresponding IDL definitions are as follows:

[0105] struct <servicename>FieldRequestTopic{

[0106] dds::rpc::RequestHeaderheader;

[0107] <servicename>FieldCall union_data;

[0108] };

[0109] struct <servicename>FieldReplyTopic{

[0110] dds::rpc::ReplyHeaderheader;

[0111] <servicename>FieldReturn union_data;

[0112] };

[0113] It should be noted that the communication endpoint allocation of the field and its performance under multiple service instances are exactly the same as those corresponding to events and methods. The data between different instances are also separated by the @key field of idl, and the data reader and data writer are separated by Partition QoS.

[0114] S103: Allocate a transmission endpoint and configure QoS for the DDS Topic after service mapping.

[0115] For Event or Field (when hasNotifier is True), since they use DDS Topic for publish / subscribe communication, these communication behaviors are indeed no different from ordinary DDS communication at the DDS layer. Therefore, the QoS (Quality of Service) parameters acting on the Topic, DataReader and DataWriter endpoints can be configured to meet different application requirements. These QoS parameters may include reliability, durability, history, etc., which together determine how data is transmitted and processed in the DDS network.

[0116] For Method or Field (when hasGetter / hasSetter is True), the Reliability QoS of its endpoint must be set to Reliable, the Durability QoS must be set to Volatile, and the History QoS must be set to Keep_All. The QoS of other endpoints can be configured as needed.

[0117] Among them, Reliability QoS must be set to Reliable to ensure that data is not lost during transmission and that the receiver can confirm the receipt of data. This is critical to ensuring the correctness of Method calls and data integrity. Durability QoS must be set to Volatile, which means that when a new DataReader joins, it will not receive data that has been published but not read before. This is usually acceptable for Method calls because Method calls are usually immediate and synchronous, and there is no need to retain historical data for subsequent DataReaders. History QoS must be set to Keep_All, which means that DDS will retain all published but not yet read data until they are read or expired. For Method calls, although it is usually not necessary to retain a large amount of historical data, since Method calls may be based on a request-response model, retaining all historical data can ensure that the data can be reprocessed or queried when needed.

[0118] In summary, the embodiment of the present application provides a data transmission method, which includes: connecting the server and the client through the data distribution service DDS; when using the data writer to write the service data to the DDS, using the events, methods and fields defined in the service interface, the service data is mapped to the corresponding DDS topic, so that the data reader of the server can read the service data by reading the DDS topic. Thus, the service data can be transmitted through the DDS protocol, providing QoS controlled data sharing, realizing communication between applications through the publish and subscribe mechanism, and having the characteristics of high efficiency, real-time and reliability.

[0119] See also Figure 5 , which is a schematic diagram of a data transmission device provided in an embodiment of the present application. The data transmission device 500 includes: a connection module 501 and a mapping module 502;

[0120] The connection module 501 is used to connect the server and the client through the data distribution service DDS;

[0121] The mapping module 502 is used to map the service data to the corresponding subject of the DDS by using the events, methods and fields defined in the service interface when writing the service data to the DDS using the data writer, so that the data reader on the server side can read the service data by reading the subject of the DDS.

[0122] Optionally, the mapping module 502 specifically includes: a first submodule and a second submodule;

[0123] The first submodule is used to create a target DDS topic according to the to-be-published events defined in the service interface and the data structure of the to-be-published events by using a preset naming rule;

[0124] The second submodule is used to map the service data to the target DDS topic using the event to be published.

[0125] Optionally, the mapping module 502 specifically includes: a third submodule and a fourth submodule;

[0126] The third submodule is used to create a reply topic using the method defined in the service interface;

[0127] The fourth submodule is used to map the method to be published to the request subject through the data writer in the server, so that the data reader of the server reads the service data by reading the reply subject.

[0128] Optionally, the mapping module 502 specifically includes: a fifth submodule, a sixth submodule and a seventh submodule;

[0129] The fifth submodule is used to obtain the target attribute in the field;

[0130] The sixth submodule is used for creating a target DDS topic according to the to-be-published fields defined in the service interface and the data structure of the to-be-published fields by a preset naming rule when the target attribute is the first value; and mapping the service data to the target DDS topic by using the to-be-published fields;

[0131] The seventh submodule is used to create a reply subject using the fields defined in the service interface when the target attribute is the second value; map the fields to be published to the request subject through the data writer in the server, so that the data reader of the server reads the service data by reading the reply subject.

[0132] Optionally, the device further includes: a first configuration module and a second configuration module;

[0133] The first configuration module is used to configure the service quality of the DDS if the definition item in the service interface is an event or a field of a first value;

[0134] The second configuration module is used to configure the remaining service qualities after the reliability service quality of the DDS is confirmed as reliable, the persistence service quality is confirmed as volatile, and the historical service quality is confirmed as fully retained if the definition item in the service interface is a method or a field of the second value.

[0135] In summary, the embodiment of the present application provides a data transmission device, service data can be transmitted through the DDS protocol, QoS controlled data sharing is provided, and communication between applications is realized through a publish and subscribe mechanism, which has the characteristics of high efficiency, real-time and reliability.

[0136] Furthermore, the present application also discloses an electronic device. Figure 6 , which is a structural diagram of an electronic device provided in an embodiment of the present application. It should be noted that the content in the figure cannot be regarded as any limitation on the scope of use of the present application. The electronic device 20 may specifically include: at least one processor 21, at least one memory 22, a power supply 23, a communication interface 24, an input / output interface 25 and a communication bus 26. Among them, the memory 22 is used to store a computer program, and the computer program is loaded and executed by the processor 21 to implement the relevant steps in the method disclosed in any of the aforementioned embodiments. In addition, the electronic device 20 in this embodiment may specifically be an electronic computer.

[0137] In this embodiment, the power supply 23 is used to provide working voltage for each hardware device on the electronic device 20; the communication interface 24 can create a data transmission channel between the electronic device 20 and the external device, and the communication protocol it follows is any communication protocol that can be applied to the technical solution of the present application, and is not specifically limited here; the input and output interface 25 is used to obtain external input data or output data to the outside world, and its specific interface type can be selected according to specific application needs and is not specifically limited here.

[0138] In addition, the memory 22, as a carrier for storing resources, can be a read-only memory, a random access memory, a disk or an optical disk, etc. The resources stored thereon can include an operating system 221, a computer program 222, etc., and the storage method can be temporary storage or permanent storage.

[0139] The operating system 221 is used to manage and control the hardware devices and computer programs 222 on the electronic device 20, which can be Windows Server, Netware, Unix, Linux, etc. In addition to including computer programs that can be used to complete the method performed by the electronic device 20 disclosed in any of the aforementioned embodiments, the computer program 222 can further include computer programs that can be used to complete other specific tasks.

[0140] Furthermore, the present application also discloses a computer-readable storage medium for storing a computer program; wherein the computer program, when executed by a processor, implements the aforementioned disclosed method. The specific steps of the method can refer to the corresponding contents disclosed in the aforementioned embodiments, and will not be repeated here.

[0141] In this specification, each embodiment is described in a progressive manner, and each embodiment focuses on the differences from other embodiments. The same or similar parts between the embodiments can be referred to each other. For the device disclosed in the embodiment, since it corresponds to the method disclosed in the embodiment, the description is relatively simple, and the relevant parts can be referred to the method part.

[0142] Professionals may further appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of the two. In order to clearly illustrate the interchangeability of hardware and software, the composition and steps of each example have been generally described in the above description according to function. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professionals and technicians may use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of this application.

[0143] The steps of the method or algorithm described in conjunction with the embodiments disclosed herein may be implemented directly using hardware, a software module executed by a processor, or a combination of the two. The software module may be placed in a random access memory (RAM), a memory, a read-only memory (ROM), an electrically programmable ROM, an electrically erasable programmable ROM, a register, a hard disk, a removable disk, a CD-ROM, or any other form of storage medium known in the art.

[0144] Finally, it should be noted that, in this article, relational terms such as first and second, etc. are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Moreover, the terms "comprise", "include" or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, article or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, article or device. In the absence of further restrictions, an element defined by the statement "comprises a..." does not exclude the presence of other identical elements in the process, method, article or device including the element.

[0145] The technical solution provided by the present application is introduced in detail above. Specific examples are used in this article to illustrate the principles and implementation methods of the present application. The description of the above embodiments is only used to help understand the method of the present application and its core idea. At the same time, for general technicians in this field, according to the idea of ​​the present application, there will be changes in the specific implementation methods and application scope. In summary, the content of this specification should not be understood as a limitation on the present application.< / servicename> < / servicename> < / servicename> < / servicename> < / fieldtypename> < / fieldtypename> < / servicename> < / servicename> < / servicename> < / servicename> < / servicename> < / eventtypename> < / eventtypename> < / eventtypename> < / servicename> < / svcminversion> < / svcmajversion> < / svcinid> < / svcid> < / svcminversion> < / svcmajversion> < / svcinid> < / svcid>

Claims

1. A data transmission method, characterized in that: Applied to the server, the method includes: Connecting the server and the client via a data distribution service DDS; When the service data is written into the DDS using a data writer, the service data is mapped to the corresponding subject of the DDS using the events, methods and fields defined in the service interface, so that the data reader can read the service data by reading the subject of the DDS.

2. The method according to claim 1, characterized in that The method defined in the service interface is used to map the service data to the corresponding subject of the DDS, so that the data reader reads the service data by reading the subject of the DDS, including: Using the method defined in the service interface, create a reply topic; The method to be published is mapped to the request subject through the data writer in the server, so that the data reader reads the service data by reading the reply subject.

3. The method according to claim 1, characterized in that The method of mapping the service data to the corresponding subject of the DDS by using the fields defined in the service interface so that a data reader reads the service data by reading the subject of the DDS includes: Obtaining a target attribute in the field, wherein the target attribute is used to determine an event type corresponding to the field; When the target attribute indicates that the event type corresponding to the field is a first type event, according to the to-be-published fields defined in the service interface and the data structure of the to-be-published fields, a target DDS topic matching the first type event is created by a preset naming rule; and the service data is mapped to the target DDS topic by using the to-be-published fields; When the target attribute indicates that the event type corresponding to the field is a second type event, a reply subject is created using the fields defined in the service interface; the fields to be published are mapped to the request subject through a data writer, so that a data reader can read the service data by reading the reply subject.

4. The method according to claim 1, characterized in that: The method further comprises: If the definition item in the service interface is an event or a field of a first value, configuring the service quality of the DDS; If the definition item in the service interface is a method or a field of the second value, after the reliability service quality of the DDS is confirmed to be reliable, the persistence service quality is confirmed to be volatile, and the history service quality is confirmed to be fully retained, the remaining service qualities are configured.

5. The method according to claim 1, characterized in that Before executing the step of writing the service data into the DDS by using the data writer, mapping the service data to the corresponding subject of the DDS by using the events, methods and fields defined in the service interface, the method further comprises: A corresponding DDS topic is allocated to each to-be-published event defined in the service interface, and a data reader and a data writer are allocated to each of the DDS topics.

6. A data transmission device, characterized in that: The device comprises: a connection module and a mapping module; The connection module is used to connect the server and the client through the data distribution service DDS; The mapping module is used to map the service data to the corresponding subject of the DDS by using the events, methods and fields defined in the service interface when the service data is written into the DDS by using the data writer, so that the data reader can read the service data by reading the subject of the DDS.

7. The device according to claim 6, characterized in that The mapping module specifically includes: a first submodule and a second submodule; The first submodule is used to create a reply topic using the method defined in the service interface; The second submodule is used to map the method to be published to the request subject through the data writer in the server, so that the data reader of the server reads the service data by reading the reply subject.

8. The device according to claim 6, characterized in that The mapping module specifically includes: a third submodule, a fourth submodule and a fifth submodule; The third submodule is used to obtain a target attribute in the field, where the target attribute is used to determine the event type corresponding to the field; The fourth submodule is used for, when the target attribute indicates that the event type corresponding to the field is a first type of event, creating a target DDS topic matching the first type of event according to the to-be-published fields defined in the service interface and the data structure of the to-be-published fields by a preset naming rule; and mapping the service data to the target DDS topic by using the to-be-published fields; The fifth submodule is used to create a reply subject using the fields defined in the service interface when the target attribute indicates that the event type corresponding to the field is a second type of event; and map the fields to be published to the request subject through a data writer, so that the data reader reads the service data by reading the reply subject.

9. An electronic device, characterized in that: The electronic device comprises: a memory and a processor; The memory is used to store programs; The processor is used to execute the program to implement each step of the method according to any one of claims 1 to 5.

10. A computer storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, each step of the method according to any one of claims 1 to 5 is implemented.

Images