Vehicle, communication method thereof, transmitting end and receiving end

Abstract

The embodiment of the invention provides a vehicle and a communication method thereof, a sending end and a receiving end, and after the sending end sends a first service request to the receiving end based on an SOME / IP protocol and a UDP protocol, a second service request can be sent to the receiving end under the condition that response information for the first service request is not received. As the second service request is a repeated request for the first service request, the receiving end can only respond to one of the first service request and the second service request. Therefore, by repeatedly sending the same service request, it is ensured that the server can receive and successfully respond to the service request, and compared with the related technology, the reliability of interaction between the sending end and the receiving end is improved. Meanwhile, the first service request and the second service request only have different message types, so that the first service request and the second service request can be distinguished only based on the message types, and the complexity of distinguishing the first service request and the second service request is reduced.

Description

TECHNICAL FIELD

[0001] The present application belongs to the technical field of communication, and particularly relates to a vehicle and a communication method, a sending end and a receiving end thereof. BACKGROUND

[0002] In the field of communication technology, any two electronic control units (ECUs) in a vehicle can interact based on a Scalable service-Oriented Middleware over Internet Protocol (SOME / IP) protocol and a User Datagram Protocol (UDP).

[0003] However, in some abnormal situations (for example, network abnormality between two electronic control units), one electronic control unit can fail to receive a service request sent by another electronic control unit, thereby resulting in low reliability of interaction between the two electronic control units. SUMMARY

[0004] Embodiments of the present application provide a vehicle and a communication method, a sending end and a receiving end thereof, to solve the problem of low reliability of interaction between two electronic control units in the related art.

[0005] A first aspect of embodiments of the present application provides a vehicle communication method, applied to a sending end, and the method comprises the following steps.

[0006] sending a first service request to a receiving end based on a SOME / IP protocol and a UDP protocol;

[0007] in a case where no response information is received for the first service request, sending a second service request to the receiving end, so that the receiving end only responds to one of the first service request and the second service request.

[0008] wherein the first service request and the second service request only differ in message type.

[0009] Optionally, the method further comprises the following steps.

[0010] updating a field value of a message type field in the first service request to a target field value to obtain the second service request.

[0011] Optionally, after the second service request is sent to the receiving end, the method further comprises the following steps.

[0012] In a case where no response information for the first service request and the second service request is received, the second service request is sent to the receiving end again, so that the receiving end only responds to one of the first service request and the two second service requests.

[0013] Optionally, sending the second service request to the receiving end comprises:

[0014] In a case where the number of times of sending the second service request is less than a threshold, the second service request is sent to the receiving end.

[0015] The second aspect of the embodiments of the present application provides another vehicle communication method, applied to a receiving end, and the method comprises:

[0016] In a case where at least one of the first service request and the second service request is received, only response information for one of the service requests is sent to the sending end;

[0017] The first service request and the second service request are different only in message type.

[0018] Optionally, after the first service request is received, the method further comprises:

[0019] If the second service request is received and a field value of a message type field in the second service request is a target field value, the second service request is not responded to.

[0020] Optionally, not responding to the second service request comprises:

[0021] If a target identifier is stored, the second service request is not responded to.

[0022] The target identifier stored is used to represent that response information for the first service request has been sent to the sending end.

[0023] The third aspect of the embodiments of the present application provides a vehicle communication device, and the device comprises:

[0024] A first transceiving module is configured to send a first service request to a receiving end based on a SOME / IP protocol and a UDP protocol, and in a case where no response information for the first service request is received, a second service request is sent to the receiving end, so that the receiving end only responds to one of the first service request and the second service request; the first service request and the second service request are different only in message type.

[0025] Optionally, the first transceiving module is further configured to update a field value of a message type field in the first service request to a target field value, so as to obtain the second service request.

[0026] Optionally, the first transceiving module is further configured to, after sending the second service request to the receiving end, if no response information is received for the first service request and the second service request, send the second service request to the receiving end again, so that the receiving end responds to only one of the first service request and the two second service requests.

[0027] Optionally, the first transceiving module is configured to, if the number of times of sending the second service request is less than a threshold, send the second service request to the receiving end.

[0028] The fourth aspect of the embodiments of the present application provides another vehicle communication device, and the device comprises:

[0029] The second transceiving module is configured to, if at least one of the first service request and the second service request is received, send response information for only one of the service requests to the sending end; wherein the first service request and the second service request only differ in message type.

[0030] Optionally, the second transceiving module is further configured to, after receiving the first service request, if the second service request is received and a field value of a message type field in the second service request is a target field value, not respond to the second service request.

[0031] Optionally, the second transceiving module is configured to, if a target identifier is stored, not respond to the second service request; wherein the stored target identifier is used to represent that response information for the first service request has been sent to the sending end.

[0032] The fifth aspect of the embodiments of the present application provides a sending end, comprising: a processor configured to be connected with a memory, wherein the memory stores a computer program or instruction which can be run on the processor, and the computer program or instruction is executed by the processor to implement the vehicle communication method according to any one of the first aspect.

[0033] The sixth aspect of the embodiments of the present application provides a receiving end, comprising: a processor configured to be connected with a memory, wherein the memory stores a computer program or instruction which can be run on the processor, and the computer program or instruction is executed by the processor to implement the vehicle communication method according to any one of the second aspect.

[0034] The seventh aspect of the embodiments of the present application provides a vehicle, comprising the sending end according to the fifth aspect and the receiving end according to the sixth aspect.

[0035] The eighth aspect of the embodiments of the present application provides a computer readable storage medium, wherein the computer readable storage medium stores computer programs or instructions, and the computer programs or instructions are executed by a processor to implement the vehicle communication method according to any one of the first aspect or implement the vehicle communication method according to any one of the second aspect.

[0036] The ninth aspect of the embodiments of the present application provides a computer program product, comprising computer programs or instructions, and the computer programs or instructions are executed by a processor to implement the vehicle communication method according to any one of the first aspect or implement the vehicle communication method according to any one of the second aspect.

[0037] The vehicle and the communication method thereof, the sending end and the receiving end provided by the embodiments of the present application can send a second service request to the receiving end when the first service request is not received in response to the first service request based on the SOME / IP protocol and the UDP protocol. Since the second service request is a repeated request for the first service request, the receiving end can only respond to one of the first service request and the second service request. Thus, by repeatedly sending the same service request, it is ensured that the server can receive and successfully respond to the service request, and the interaction reliability between the sending end and the receiving end is improved compared with the related art. At the same time, since the first service request and the second service request are only different in message type, the first service request and the second service request can be distinguished based on the message type only, and thus the complexity of distinguishing the first service request and the second service request is reduced. BRIEF DESCRIPTION OF DRAWINGS

[0038] Figure 1 A structural schematic diagram of a vehicle provided by the embodiments of the present application is shown in the figure;

[0039] Figure 2 A flowchart of a vehicle communication method provided by the embodiments of the present application is shown in the figure;

[0040] Figure 3 A flowchart of another vehicle communication method provided by the embodiments of the present application is shown in the figure;

[0041] Figure 4 A flowchart of still another vehicle communication method provided by the embodiments of the present application is shown in the figure;

[0042] Figure 5 A flowchart of yet another vehicle communication method provided by the embodiments of the present application is shown in the figure;

[0043] Figure 6 A flowchart of still another vehicle communication method provided by the embodiments of the present application is shown in the figure;

[0044] Figure 7A flowchart of another vehicle communication method provided by an embodiment of the present application is shown in FIG. 2.

[0045] Figure 8 A structural diagram of a vehicle communication device provided by an embodiment of the present application is shown in FIG. 3.

[0046] Figure 9 A structural diagram of another vehicle communication device provided by an embodiment of the present application is shown in FIG. 4. DETAILED DESCRIPTION

[0047] The technical solutions in the embodiments of the present application will be clearly described below with reference to the drawings in the embodiments of the present application. Obviously, the described embodiments are only some of the embodiments of the present application, but not all of them. Based on the embodiments in the present application, all other embodiments obtained by a person of ordinary skill in the art belong to the scope of protection of the present application.

[0048] The terms "first", "second", and the like in the present application are used to distinguish similar objects, and are not used to describe a specific order or sequence. It should be understood that the terms used in this way can be interchanged under appropriate circumstances, so that the embodiments of the present application can be implemented in an order other than that illustrated or described herein, and the objects distinguished by "first", "second" are generally of a kind and do not limit the number of objects, for example, the first object can be one or more. In addition, "or" in the present application means at least one of the connected objects. For example, "A or B" covers three scenarios, namely, scenario one: including A and not including B; scenario two: including B and not including A; scenario three: including A and B. The character " / " generally represents that the objects before and after are in an "or" relationship.

[0049] The term "indication" in the present application can be a direct indication (or explicit indication) or an indirect indication (or implicit indication). Among them, the direct indication can be understood as that the sender explicitly informs the receiver of specific information, operations to be performed or requested results, etc. in the sent indication; the indirect indication can be understood as that the receiver determines the corresponding information according to the indication sent by the sender, or judges and determines the operation to be performed or the requested result according to the judgment result.

[0050] Figure 1 A structural diagram of a vehicle provided by an embodiment of the present application is shown in FIG. 1. Figure 1 As shown in FIG. 1, the vehicle includes a sending end 11 and a receiving end 12, the sending end 11 is configured to send a service request to the receiving end 12, and the receiving end 12 is configured to send response information to the sending end 11 in response to the service request.

[0051] Among them, the sending end 11 involved in the embodiments of the present application can be an ECU requesting services in the vehicle, including but not limited to: Advanced Driver Assistance Systems (ADAS) and central control unit, etc.; the receiving end 12 can be an ECU providing services in the vehicle, including but not limited to: body controller and infotainment system, etc.

[0052] The communication scenario between the sending end 11 and the receiving end 12 includes but is not limited to: the service request sent by the ADAS system to the camera controller can be a service request for obtaining road condition data, and the service request sent by the central control unit to the body controller can be a service request for obtaining door status information.

[0053] The technical solutions of the vehicle communication method of the present application will be described below with several specific embodiments as examples:

[0054] Figure 2 A flowchart of a vehicle communication method provided by the embodiments of the present application is shown in FIG. 1, and the flow of the method of the present embodiment is as follows: Figure 2

[0055] S21: The sending end sends a first service request to the receiving end based on the SOME / IP protocol and the UDP protocol.

[0056] Among them, the SOME / IP protocol is a protocol for service-oriented communication on an IP network, and the sending end will send a service request to the receiving end only when it needs to, and receive a response returned by the receiving end. The SOME / IP protocol supports the Remote Procedure Call (RPC) mechanism and can realize efficient service request and service provision between distributed software organizations in the vehicle; the UDP protocol is a connectionless transport layer protocol, which supports unicast, broadcast, multicast and anycast data transmission modes, and can meet the transmission needs of a large amount of data in the vehicle network.

[0057] The sending end can encapsulate all service requests sent to the receiving end into messages and send them to the receiving end in the form of messages. For example, the service request can be a first service request.

[0058] ​The message can include a first header and a payload. The first header can include a message type field, which is represented by 8 bits. For example, the message type field can have a value of 0x00, which represents a request expecting a response (REQUEST). The message type field can have a value of 0x01, which represents a request not expecting a response (REQUEST_NO_RETURN). The message type field can have a value of 0x02, which represents a notification (NOTIFICATION).

[0059] In an example, the first service request is a request expecting a response, and the message type field of the first service request can have a value of 0x00.

[0060] The sending end sends the first service request to the receiving end based on the SOME / IP protocol and the UDP protocol. The process includes:

[0061] The sending end encapsulates the first service request into a SOME / IP message according to the SOME / IP protocol. The SOME / IP message includes a first header and a payload. Then, the sending end encapsulates the SOME / IP message into a UDP message by adding a second header to the SOME / IP message. The sending end encapsulates the UDP message into an IP data message by adding a third header to the UDP message. Then, the sending end transmits the IP data message to the receiving end through an Ethernet.

[0062] S22: The sending end sends a second service request to the receiving end in a case where the sending end does not receive response information for the first service request, so that the receiving end responds to only one of the first service request and the second service request. The first service request and the second service request are different only in message type.

[0063] Since the first service request and the second service request are different only in message type, the second service request can be considered as a repeated request for the first service request. Therefore, the receiving end only needs to respond to one of the first service request and the second service request.

[0064] Optionally, the sending end can be provided with a timer, and the sending end can prestore a timing threshold. Specifically, after the sending end sends the first service request to the receiving end based on the SOME / IP protocol and the UDP protocol, the sending end can start the timer to time. If the sending end does not receive response information for the first service request before the timing of the timer reaches the timing threshold, the sending end can send the second service request to the receiving end based on the SOME / IP protocol and the UDP protocol.

[0065] Due to network congestion, software and hardware failure of the receiving end, or limited software and hardware processing capability of the receiving end, the first service request can be lost or the first service request can be delayed to reach the receiving end. If the first service request is lost, the receiving end does not receive the first service request, and the corresponding sending end also does not receive the response information for the first service request before the timer reaches the timing threshold. The sending end can then send a second service request to the receiving end. Since the second service request is a repeated request for the first service request, the receiving end can respond to the second service request only when the second service request is received.

[0066] If the first service request is delayed to reach the receiving end, the receiving end will not send response information for the first service request before the timer reaches the timing threshold. And due to the order guarantee mechanism of Ethernet, multiple service requests can be guaranteed to reach the receiving end in the order of sending. Since the first service request is sent before the second service request, the first service request will reach the receiving end before the second service request. The receiving end can then respond to the first service request. After receiving the second service request, since the second service request is a repeated request for the first service request, the receiving end can not respond to the second service request after responding to the first service request.

[0067] In related technologies, the sending end will resend the first service request without receiving the response information for the first service request. Each first service request has the same message type. The receiving end receives and responds to the first first service request. The receiving end also responds to the first service request that is resent. This causes the receiving end to perform an unnecessary response.

[0068] In the embodiments of the present application, since the second service request is a repeated request for the first service request, the receiving end can only respond to one of the first service request and the second service request. This improves the reliability of interaction between the sending end and the receiving end, and avoids the receiving end performing an unnecessary response.

[0069] In this embodiment, after the sending end sends the first service request to the receiving end based on the SOME / IP protocol and the UDP protocol, the sending end can send the second service request to the receiving end in the case where the response information for the first service request is not received. Since the second service request is a repeated request for the first service request, the receiving end can respond to only one of the first service request and the second service request. Thus, by repeatedly sending the same service request, it is ensured that the server can receive and successfully respond to the service request, and the interaction reliability between the sending end and the receiving end is improved compared with the related art. Meanwhile, since the first service request and the second service request are different only in the message type, the first service request and the second service request can be distinguished based on only the message type, without distinguishing the first service request and the second service request by multiple parameters, and thus the complexity of distinguishing the first service request and the second service request is reduced.

[0070] Figure 3 Another flowchart of a vehicle communication method provided by an embodiment of the present application is shown in Figure 3 based on Figure 2 , further, a possible implementation of the second service request obtained in S22 is described as follows. Figure 3 The flow of the method of this embodiment is as follows.

[0071] S31: The sending end updates the field value of the message type field in the first service request to a target field value to obtain the second service request, and sends the second service request to the server.

[0072] The second service request and the first service request are the same service request, and are different only in the message type field. The target field value is an extended message type segment value, and is used to identify that the second service request is the repeated first service request.

[0073] Specifically, the message type field value in the first service request is 0x00, and one possible representation of the target field value is 0x03. The sending end can update the message type field value corresponding to the first service request from 0x00 to 0x03 to obtain the second service request.

[0074] In this embodiment, the sending end updates the field value of the message type field in the first service request to the target field value to obtain the second service request, so that the difference between the first service request and the second service request is explicitly identified, which is helpful for the receiving end to determine that the second service request is a repeated request for the first service request.

[0075] Figure 4 Another flowchart of a vehicle communication method provided by an embodiment of the present application is shown in Figure 4 based on Figure 2On the basis of the above, further, the scenario of sending the second service request again can also be included, such as Figure 4 As shown in the figure, the flow of the method of the embodiment is as follows:

[0076] S23: The sending end sends the second service request to the receiving end again in the case that the response information for the first service request and the second service request is not received, so that the receiving end only responds to the first service request and one of the two second service requests.

[0077] Wherein, after the sending end sends the second service request to the receiving end, the timer can be restarted. If the sending end has not received the response information for the second service request before the timer reaches the timing threshold, and also has not received the response information for the first service request, the sending end can send the second service request to the receiving end again.

[0078] Specifically, if the first service request and the first sent second service request are both lost, the receiving end also cannot receive the first sent second service request, and correspondingly, the sending end also cannot receive the response information for the first sent second service request before the timer reaches the timing threshold. Therefore, the sending end can send the second service request to the receiving end again. Since the second sent second service request is also a repeated request for the first service request, the receiving end can respond to the second sent second service request in the case that only the second sent second service request is received.

[0079] If the first service request is lost, and the first sent second service request is delayed to reach the receiving end, the receiving end will not send the response information for the first sent second service request before the timer reaches the timing threshold. And due to the order guarantee mechanism of Ethernet, it can be ensured that multiple service requests reach the receiving end in the order of sending, so the first sent second service request will reach the receiving end before the second sent second service request. Then the receiving end can respond to the first sent second service request first, and after receiving the second sent second service request, since the second sent second service request is also a repeated request for the first service request, the receiving end can not respond to the second sent second service request after responding to the first sent second service request.

[0080] If the first service request and the first sent second service request successively arrive at the receiving end after the sending end sends the second service request for the second time, the receiving end will not send a response message for the first service request and the first sent second service request. Due to the order guarantee mechanism of the Ethernet, the multiple service requests can be guaranteed to arrive at the receiving end in the sending order, and thus the first service request, the first sent second service request and the second sent second service request will arrive at the receiving end in turn after the sending end sends the second service request for the second time, and the receiving end can respond to the first service request first. After receiving the first sent second service request and the second sent second service request, the receiving end can not respond to the first sent second service request and the second sent second service request since the first sent second service request and the second sent second service request are both repeated requests of the first service request.

[0081] In the embodiment, the sending end sends the second service request to the receiving end again without receiving the response information for the first service request and the second service request. Since the two second service requests are both repeated requests of the first service request, the receiving end can respond to only one of the first service request and the two second service requests, thereby ensuring that the service request can arrive at the receiving end and improving the reliability of the interaction between the sending end and the receiving end.

[0082] In the above embodiment, optionally, the sending end can send the second service request to the receiving end in the case that the sending number of the second service request is less than the number threshold.

[0083] Before sending the second service request each time, the sending end can detect whether the sending number of the second service request is less than the number threshold. In the case that the sending number of the second service request is less than the number threshold, the sending end can send the second service request to the receiving end. In the case that the sending number of the second service request is greater than or equal to the number threshold, the sending end does not need to send the second service request to the receiving end.

[0084] The number threshold of the retransmission request, that is, the number threshold of the second service request, can be pre-stored in the sending end, and the sending end can send the second service request to the receiving end no more than the number threshold, thereby avoiding resource waste.

[0085] For example, the number threshold of the second service request is 7 times. If the sending end does not receive the response information for the second service request before the timer reaches the timing threshold after the timer is restarted each time, the second service request is sent for 7 times in turn.

[0086] In some embodiments, before the timing of the timer reaches the timing threshold, the receiving end receives the first service request and sends the response information for the first service request to the sending end.

[0087] Figure 5 A flowchart of another vehicle communication method provided by the embodiments of the present application is shown in FIG. 6. Figure 5 Figure 4 Further, the method further comprises that the receiving end only sends the response information for one service request to the sending end, as shown in FIG. 5. Figure 5 The flow of the method of the embodiments is shown in FIG. 6.

[0088] S51: The receiving end only sends the response information for one service request to the sending end in the case that the receiving end receives at least one of the first service request and the second service request, wherein the first service request and the second service request are only different in message type.

[0089] If the sending end sends the first service request and sends the second service request again based on the timeout of the timer, the first service request and the second service request are only different in message type, which indicates that the receiving end is expected to determine that the received is a repeated request based on the message type and thus only respond once. Therefore, based on the different message types, the receiving end can know that the received second service request is a repeated request, and thus only respond to one of the first service request and the second service request.

[0090] Specifically, whether the first service request is lost, resulting in that the receiving end only receives the second service request, or the first service request is delayed to arrive at the receiving end after the sending end sends the second service request, resulting in that the receiving end receives both the first service request and the second service request, the receiving end only sends the response information for one service request to the sending end.

[0091] Further, the response information sent by the receiving end is also encapsulated into a SOME / IP message, and the response information of the receiving end for the first service request and the second service request is the same, wherein the field value of the message type field can be 0x80, 0x80 indicating the response information (RESPONSE), and the field value of the message type field can also be 0x81, 0x81 indicating the error message (ERROR).

[0092] In the embodiments, the receiving end only sends the response information for one service request to the sending end in the case that the receiving end receives at least one of the first service request and the second service request, wherein the first service request and the second service request are only different in message type, so that the same request is only responded once, which helps to ensure the stability and reliability of the system.

[0093] ​In the above embodiment, if the sending end sends the second service request to the receiving end again without receiving the response information of the first service request and the second service request, no matter whether the first service request and the first sent second service request are lost, resulting in that the receiving end only receives the second sent second service request; or the first service request is lost, the first sent second service request is delayed to arrive at the receiving end after the sending end sends the second service request again, resulting in that the receiving end receives the first sent second service request and the second sent second service request; or the first service request and the first sent second service request are both delayed to arrive at the receiving end after the sending end sends the second service request again, resulting in that the receiving end receives the first service request and the twice sent second service request, the receiving end also only sends the response information of one service request to the sending end.

[0094] Figure 6 A flowchart of another vehicle communication method provided by an embodiment of the present application is shown in Figure 6 Figure 5 On the basis of Figure 6 , a possible implementation of the method of the embodiment is described as follows.

[0095] S511: If the receiving end receives the second service request after receiving the first service request, and the field value of the message type field in the second service request is the target field value, the receiving end does not respond to the second service request.

[0096] In the embodiment, the message type field value of the first service request received by the receiving end is 0x00, if the receiving end receives the second service request, and the message type field value of the second service request is the target field value such as 0x03, the receiving end determines that the second service request is a repeated request for the first service request, and does not respond to the second service request.

[0097] In the embodiment, if the receiving end receives the second service request after receiving the first service request, and the field value of the message type field in the second service request is the target field value, the receiving end can not respond to the second service request, that is, the first service request and the second service request only have one different message type field, and the receiving end only needs to distinguish the two service requests based on one field, thereby improving the efficiency of distinguishing the first service request and the second service request.

[0098] Figure 7 A flowchart of another vehicle communication method provided by an embodiment of the present application is shown in Figure 7 Figure 6 ​​on the basis of S241, a possible implementation of not responding to the second service request is described as follows Figure 7 The flow of the method of the embodiment is as follows:

[0099] S71: If the receiving end stores the target identifier, the receiving end does not respond to the second service request.

[0100] The stored target identifier is used to represent that the response information for the first service request has been sent to the sending end.

[0101] Specifically, one possible generation manner of the target identifier is that when the first service request is sent, a Globally Unique Identifier (GUID) field is added in the payload part of the SOME / IP message corresponding to the first service request, and the first four bytes are defined as the GUID, and monotonically increased within one ignition cycle. Assuming that the first service request corresponds to a GUID1, when the sending end sends the second service request, the GUID1 is copied.

[0102] Further, another possible generation manner of the target identifier is that the receiving end generates the target identifier when responding to the first service request.

[0103] It can be understood that, taking the generation of the GUID field in the payload as the target identifier as an example, in the case that the first service request arrives at the receiving end before the second service request, after the receiving end sends a response information to the sending end for the first service request, the receiving end stores the GUID1, and when the second service request is received, the receiving end determines that the GUID1 has been stored by querying, and then does not respond to the second service request.

[0104] It can also be understood that, in the case that the first service request is lost, the first sent second service request arrives at the receiving end before the second sent second service request, after the receiving end sends a response information to the sending end for the first sent second service request, the receiving end stores the GUID1, and when the second second service request is received, the receiving end determines that the GUID1 has been stored by querying, and then does not respond to the second sent second service request.

[0105] In the embodiment, if the receiving end stores the target identifier, the receiving end does not respond to the second service request; the stored target identifier is used to represent that the response information for the first service request has been sent to the sending end, thereby avoiding repeated processing of the same request and improving the reliability of the system.

[0106] Figure 8 A structural schematic diagram of a vehicle communication device provided by the embodiment of the present application is shown in FIG. 1. Figure 8As shown in the figure, the device comprises: a first transceiving module 801, configured to send a first service request to a receiving end based on a SOME / IP protocol and a UDP protocol; and in a case where no response information is received for the first service request, send a second service request to the receiving end, so that the receiving end responds to only one of the first service request and the second service request; wherein the first service request and the second service request only differ in message type.

[0107] Optionally, the first transceiving module 801 is further configured to update a field value of a message type field in the first service request to a target field value, to obtain the second service request.

[0108] Optionally, the first transceiving module 801 is further configured to, after sending the second service request to the receiving end, in a case where no response information is received for the first service request and the second service request, send the second service request to the receiving end again, so that the receiving end responds to only one of the first service request and the two second service requests.

[0109] Optionally, the first transceiving module 801 is configured to send the second service request to the receiving end in a case where a sending number of the second service request is less than a number threshold.

[0110] The device of the embodiment can be used to execute the steps performed by the sending end in the above method embodiments, and has similar implementation principles and technical effects, which will not be described here.

[0111] Figure 9 Another vehicle communication device provided by the embodiment is shown in the figure. Figure 9 As shown in the figure, the device comprises: a second transceiving module 901, configured to, in a case where at least one of a first service request and a second service request is received, send response information for only one service request to a sending end; wherein the first service request and the second service request only differ in message type.

[0112] Optionally, the second transceiving module 901 is further configured to, after receiving the first service request, if the second service request is received and a field value of a message type field in the second service request is a target field value, not respond to the second service request.

[0113] Optionally, the second transceiving module 901 is configured to, if a target identifier is stored, not respond to the second service request; wherein the stored target identifier is used to represent that the response information for the first service request has been sent to the sending end.

[0114] The device of the embodiment can be used to execute the steps performed by the receiving end in the above method embodiments, and has similar implementation principles and technical effects, which will not be described here.

[0115] The embodiment of the present application further provides a sending end, comprising: a processor, the processor being connected with a memory, the memory storing a computer program or instructions executable on the processor, and the computer program or instructions being executed by the processor to implement the vehicle communication method as described above.

[0116] The embodiment of the present application further provides a receiving end, comprising: a processor, the processor being connected with a memory, the memory storing a computer program or instructions executable on the processor, and the computer program or instructions being executed by the processor to implement the vehicle communication method as described above.

[0117] The embodiment of the present application further provides a computer readable storage medium, the readable storage medium storing a computer program or instructions, and the computer program or instructions being executed by the processor to implement the vehicle communication method as described above.

[0118] The embodiment of the present application further provides a computer program product, comprising a computer program or instructions, and the computer program or instructions being executed by the processor to implement the vehicle communication method as described above.

[0119] It should be noted that, in this document, the terms "comprising", "including", or any other variant thereof are intended to cover non-exclusive inclusions, so that the process, method, article or device including a series of elements not only includes those elements, but also includes other elements not explicitly listed, or includes elements inherent to such process, method, article or device. Without more limitations, the element defined by the statement "including a" does not exclude the presence of other identical elements in the process, method, article or device including the element. In addition, it should be pointed out that the scope of the method and device in the embodiments of the present application is not limited to performing functions in the order shown or discussed, but can also include performing functions in a substantially simultaneous manner or in reverse order according to the functions involved, for example, the described method can be performed in an order different from that described, and various steps can also be added, omitted or combined. In addition, the features described with reference to certain examples can be combined in other examples.

[0120] From the above description of the embodiments, those skilled in the art can clearly understand that the above-mentioned embodiment method can be realized by means of computer software product and general hardware platform, of course, it can also be realized by hardware. The computer software product is stored in a storage medium (such as ROM, RAM, magnetic disc, optical disc, etc.), and includes a plurality of instructions for making the terminal or network side device execute the method described in each embodiment of the present application.

[0121] The embodiments of the present application are described above with reference to the accompanying drawings, but the present application is not limited to the above-described specific embodiments, and the above-described specific embodiments are merely illustrative, but not restrictive, and a person of ordinary skill in the art can make many forms of embodiments under the inspiration of the present application without departing from the purpose of the present application and the scope protected by the claims, and these embodiments all belong to the protection of the present application.

Claims

1. A vehicle communication method, characterized in that: Applied to a sending end, the method includes: Sending a first service request to a receiving end based on the SOME / IP protocol and the UDP protocol; In a case where no response information to the first service request is received, sending a second service request to the receiving end, so that the receiving end responds to only one of the first service request and the second service request; The first service request and the second service request differ only in message type.

2. The method according to claim 1, characterized in that The method further comprises: The field value of the message type field in the first service request is updated to the target field value to obtain the second service request.

3. The method according to claim 1, characterized in that After sending the second service request to the receiving end, the method further includes: In the case that no response information to the first service request and the second service request is received, the second service request is sent to the receiving end again, so that the receiving end only responds to the first service request and one of the two second service requests.

4. The method according to any one of claims 1 to 3, characterized in that: Sending a second service request to the receiving end includes: When the number of times the second service request is sent is less than a number threshold, the second service request is sent to the receiving end.

5. A vehicle communication method, characterized in that: Applied to a receiving end, the method includes: When receiving at least one of the first service request and the second service request, only sending response information for one of the service requests to the sending end; The first service request and the second service request differ only in message type.

6. The method according to claim 5, characterized in that After receiving the first service request, the method further includes: If the second service request is received and the field value of the message type field in the second service request is the target field value, the second service request is not responded to.

7. The method according to claim 6, characterized in that Not responding to the second service request includes: If the target identifier is stored, not responding to the second service request; The stored target identifier is used to indicate that response information for the first service request has been sent to the sending end.

8. A transmitting end, characterized in that: include: A processor, the processor is used to be connected to a memory, the memory stores a computer program or instruction that can be run on the processor, and when the computer program or instruction is executed by the processor, the vehicle communication method according to any one of claims 1 to 4 is implemented.

9. A receiving end, characterized in that: include: A processor, the processor is used to be connected to a memory, the memory stores a computer program or instruction that can be run on the processor, and when the computer program or instruction is executed by the processor, the vehicle communication method according to any one of claims 5 to 7 is implemented.

10. A vehicle, characterized in that: It includes the transmitting end as claimed in claim 8 and the receiving end as claimed in claim 9.

Images