Method and device for determining communication problems between vehicle application processes

Abstract

The present invention provides a method and device for determining communication problems between vehicle application processes, which relates to the technical field of vehicle application process communication problem analysis, and includes: obtaining an abnormal communication data packet currently transmitted between vehicle application processes; determining a message type of a SOME / IP communication protocol based on a first protocol header field corresponding to the abnormal communication data packet; if the message type is service discovery, determining the communication problem between the current vehicle application processes according to a second protocol header field corresponding to the abnormal communication data packet; if the message type is service communication, determining the communication problem between the current vehicle application processes according to a third protocol header field corresponding to the abnormal communication data packet; so as to alleviate the technical problem that communication problems between vehicle applications cannot be determined immediately in the prior art.

Description

Technical Field

[0001] The present invention relates to the technical field of analyzing vehicle application process communication problems, and in particular to a method and device for determining vehicle application process communication problems. Background Art

[0002] SOME / IP (Scalable service-Oriented MiddlewarE over IP) is a communication protocol widely used in the automotive industry, which allows efficient and reliable service discovery and service invocation between different electronic control units (ECUs) over Ethernet.

[0003] The inventors have found that developers and testers often need to analyze the causes of communication problems, that is, why the other end does not respond when sending data, or why the other end returns incorrect information. However, due to the complexity of the SOME / IP protocol, the causes of such communication problems are often not known in a timely manner. Summary of the invention

[0004] In view of this, an object of the present invention is to provide a method and device for determining communication problems between vehicle application processes, so as to alleviate the technical problem in the prior art that communication problems between vehicle applications cannot be determined in real time.

[0005] In a first aspect, an embodiment provides a method for determining a communication problem between vehicle application processes, comprising:

[0006] Obtain abnormal communication data packets transmitted between current vehicle application processes;

[0007] Determine the message type of the SOME / IP communication protocol based on the first protocol header field corresponding to the abnormal communication data packet; wherein the message type includes service discovery and service communication;

[0008] If the message type is service discovery, the communication problem between the current vehicle application processes is determined according to the second protocol header field corresponding to the abnormal communication data packet; wherein the second protocol header field is used to represent the publishing status of the server and the subscription status of the client;

[0009] If the message type is service communication, the communication problem between the current vehicle application processes is determined based on the third protocol header field corresponding to the abnormal communication data packet; wherein the third protocol header field is used to characterize the client's request status and the server's processing status of the request sent by the client.

[0010] In an optional implementation, the second protocol header field includes:

[0011] The Message Type field is used to determine the current message type, the ProtocolVersion field and the Interface Version field are used to match the version, the Entries Array array is used to characterize the correctness of the server publishing process and the client subscription process, and the Options Array field is used to characterize the node configuration information of the server and the client;

[0012] The Entries Array array includes a Type field for characterizing the completion status of the service discovery and subscription process, a Service ID field for characterizing service configuration information, an Instance ID field, a Major Version field, a Minor Version field, and a TTL (Time To Live) field.

[0013] In an optional implementation, if the message type is service discovery, the step of determining the communication problem between the current vehicle application processes according to the second protocol header field corresponding to the abnormal communication data packet includes:

[0014] If the message type is service discovery, determining a second protocol header field according to a protocol header in a SOME / IP communication protocol corresponding to the service discovery;

[0015] Compare the fields in the second protocol header used to represent the service configuration information and the node configuration information with the standard configuration fields corresponding to the message type of the service discovery, and determine whether there is a communication problem with abnormal configuration between the current vehicle application processes;

[0016] Based on the content of the type field in the second protocol header, determine whether there is a communication problem between the current vehicle application processes, such as a server publishing exception and / or a client subscription exception.

[0017] In an optional implementation, the third protocol header field includes:

[0018] The Protocol Version field and Interface Version field are used to match the version, the Request ID field and Message Length field are used to represent the configuration information requested by the client, and the Message Type field and Return Code field are used to represent the processing status of the server.

[0019] In an optional implementation, if the message type is service communication, the step of determining the communication problem between the current vehicle application processes according to the third protocol header field corresponding to the abnormal communication data packet includes:

[0020] If the message type is service communication, determining a third protocol header field according to a protocol header in a SOME / IP communication protocol corresponding to the service communication;

[0021] Compare the configuration information used to characterize the client request in the third protocol header with the standard configuration information of the client request corresponding to the message type of the service communication, and determine whether there is a communication problem of abnormal client request between the current vehicle application processes;

[0022] Based on the content of the Message Type field in the third protocol header, determining whether there is a communication problem between the current vehicle application processes caused by the server processing exception;

[0023] If there is a server-side processing exception, the type of server-side processing exception existing between the current vehicle application processes is determined based on the content of the Return Code field in the third protocol header.

[0024] In an optional implementation, the step of determining the message type of the SOME / IP communication protocol based on the first protocol header field corresponding to the abnormal communication data packet includes:

[0025] Based on the abnormal communication data packet, determine the first protocol header field of the SOME / IP communication protocol; wherein the first protocol header field includes Service-ID, Method-ID and Client-ID;

[0026] If the first protocol header fields are all fixed values, the message type of the SOME / IP communication protocol is determined to be service discovery;

[0027] If there is a value change in the first protocol header field, the message type of the SOME / IP communication protocol is determined to be service communication.

[0028] In an optional implementation, the step of obtaining an abnormal communication data packet currently transmitted between vehicle application processes includes:

[0029] The communication messages between the current vehicle application processes are captured through the preset packet capture tool to generate abnormal communication data packets.

[0030] In a second aspect, an embodiment provides a device for determining a communication problem between vehicle application processes, including:

[0031] An acquisition module is used to acquire abnormal communication data packets transmitted between current vehicle application processes;

[0032] A first determination module determines a message type of the SOME / IP communication protocol based on a first protocol header field corresponding to the abnormal communication data packet; wherein the message type includes service discovery and service communication;

[0033] A second determination module, if the message type is service discovery, determines the communication problem between the current vehicle application processes according to the second protocol header field corresponding to the abnormal communication data packet; wherein the second protocol header field is used to characterize the publishing status of the server and the subscription status of the client;

[0034] The third determination module determines the communication problem between the current vehicle application processes based on the third protocol header field corresponding to the abnormal communication data packet if the message type is service communication; wherein the third protocol header field is used to characterize the client's request status and the server's processing status of the request sent by the client.

[0035] In a third aspect, an embodiment provides an electronic device, including a memory and a processor, wherein the memory stores a computer program that can be run on the processor, and when the processor executes the computer program, the steps of the method described in any of the aforementioned implementation methods are implemented.

[0036] In a fourth aspect, an embodiment provides a machine-readable storage medium, wherein the machine-readable storage medium stores machine-executable instructions. When the machine-executable instructions are called and executed by a processor, the machine-executable instructions prompt the processor to implement the steps of the method described in any one of the aforementioned implementations.

[0037] An embodiment of the present invention provides a method and device for determining communication problems between vehicle application processes. Communication data packets transmitted between processes with communication abnormalities are captured, and based on the first protocol header field, the message type of the packets can be determined to be service communication SOME / IP or service discovery SOME / IP-sd; based on different message types, specific protocol fields are extracted respectively to know the execution status between the server and the client, and then the communication problem of the application process with communication abnormality in the current vehicle is determined to facilitate timely correction.

[0038] Other features and advantages of the present disclosure will be set forth in the following description, or some features and advantages may be inferred or unambiguously determined from the description, or may be learned by implementing the above-mentioned technology of the present disclosure.

[0039] In order to make the above-mentioned objectives, features and advantages of the present disclosure more obvious and easy to understand, preferred embodiments are specifically cited below and described in detail with reference to the attached drawings. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0041] Figure 1 A flow chart of a method for determining a communication problem between vehicle application processes provided by an embodiment of the present invention;

[0042] Figure 2 A functional module diagram of a device for determining a communication problem between vehicle application processes provided by an embodiment of the present invention;

[0043] Figure 3 A schematic diagram of the hardware architecture of an electronic device provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0044] In order to make the purpose, technical solution and advantages of the embodiments of the present invention clearer, the technical solution of the present invention will be clearly and completely described below in conjunction with the accompanying drawings. Obviously, the described embodiments are part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0045] In automotive electronic systems, it is often particularly necessary to conduct real-time and effective analysis of the causes of communication problems. However, due to the complexity of the SOME / IP communication protocol, it is impossible to know the causes of communication problems in a timely manner.

[0046] Based on this, an embodiment of the present invention provides a method and device for determining communication problems between vehicle application processes. By parsing the protocol header field in the data packet with communication anomaly in the vehicle application, the communication anomaly problem is determined in time, which is convenient for quick and effective correction.

[0047] To facilitate understanding of this embodiment, a method for determining a vehicle application inter-process communication problem disclosed in an embodiment of the present invention is first introduced in detail. This method can be applied to intelligent control devices such as vehicle controllers, host computers, and servers.

[0048] Figure 1 A flow chart of a method for determining a communication problem between vehicle application processes provided by an embodiment of the present invention.

[0049] like Figure 1 As shown, the method comprises the following steps:

[0050] Step S102, obtaining abnormal communication data packets transmitted between current vehicle application processes.

[0051] Here, there are service applications between the application processes of the vehicle. If such service applications fail to be successfully implemented, the data packets sent between the application processes (server and client) when the abnormal situation occurs can be obtained. The data packets are used to characterize the abnormal communication data packets; based on the abnormal communication data packets, the communication problems between the server and the client where the service application abnormality occurs are determined.

[0052] Step S104: determining the message type of the SOME / IP communication protocol based on the first protocol header field corresponding to the abnormal communication data packet.

[0053] Among them, according to the abnormal communication data packet, the first protocol header field can be read, and then based on the content of the first protocol header field, it is determined what message type is applied between the server and the client where the service application exception currently occurs; the message type includes the service discovery SOME / IP-SD (Service Discovery) type and the service communication SOME / IP type.

[0054] Step S106, if the message type is service discovery, determine the communication problem between the current vehicle application processes according to the second protocol header field corresponding to the abnormal communication data packet.

[0055] Among them, further parsing the abnormal communication data packet can determine that the message type is the second protocol header field in the service discovery protocol header, and the second protocol header field is used to characterize the publishing status of the server and the subscription status of the client; based on the second protocol header field, the specific problem that causes the abnormal communication between the current vehicle application processes can be determined;

[0056] It is understandable that the protocol header parsing of the message type SOME / IP-SD can be used to investigate abnormal problems in applications such as service discovery and service subscription between the server and the client.

[0057] Step S108: If the message type is service communication, determine the communication problem between the current vehicle application processes according to the third protocol header field corresponding to the abnormal communication data packet.

[0058] Among them, further parsing the abnormal communication data packet can determine that the message type is the third protocol header field in the protocol header of the service communication, and the third protocol header field is used to characterize the request of the client and the processing of the request sent by the server to the client; based on the third protocol header field, the specific problem causing the abnormal communication between the current vehicle application processes can be known;

[0059] It is understandable that the protocol header parsing of the message type SOME / IP can be used to investigate abnormal problems in applications such as subscription event push and remote procedure call (RPC) methods between the server and the client.

[0060] In a preferred embodiment of actual application, communication data packets are captured and transmitted between processes where communication abnormalities occur, and based on the first protocol header field, it can be determined that the message type belongs to service communication SOME / IP or service discovery SOME / IP-sd; based on different message types, specific protocol fields are extracted respectively to know the execution status between the server and the client, and then the communication problem of the application process where the communication abnormality occurs in the current vehicle is determined, so as to facilitate timely correction.

[0061] In some embodiments, step S102 may capture data packets between application processes that have abnormal communication conditions by using a packet capture tool, including:

[0062] Step 1.1), using a preset packet capture tool to capture the communication messages between the current vehicle application processes, and generate abnormal communication data packets.

[0063] The preset packet capture tool may be a Wireshark packet capture tool, through which communication messages between SOME / IP service instances are captured and stored as .pcap format files.

[0064] It should be noted that, for the abnormal communication data packet file in .pcap format, the protocol header related information (first protocol header field) can be initially extracted by using Python language tools, that is, based on the steps of the aforementioned embodiment, the step S104 can determine the type of the abnormal message according to the first protocol header field, and then select the corresponding protocol header field for analysis, specifically including:

[0065] Step 2.1), based on the abnormal communication data packet, determine the first protocol header field of the SOME / IP communication protocol.

[0066] When parsing the header of the SOME / IP protocol data, big-endian byte order can be used for storage; based on the above-mentioned embodiment, the first protocol header field existing in both message types can be known, and the first protocol header field includes Service-ID, Method-ID and Client-ID; and then according to the content of the first protocol header field, the type of the current message can be determined.

[0067] Step 2.2), if the first protocol header fields are all fixed values, the message type of the SOME / IP communication protocol is determined to be service discovery.

[0068] For example, when Service-ID is a fixed value of 0xFFFF, Method-ID is a fixed value of 0x8100, and Client-ID is a fixed value of 0x0000, the message is of service discovery type.

[0069] Step 2.3), if there is a change in the value of the first protocol header field, the message type of the SOME / IP communication protocol is determined to be service communication.

[0070] If the content of the first protocol header field has a value change according to different scenarios, then the message is of service communication type.

[0071] In some embodiments, the data model of the SOME / IP-SD protocol header of the service discovery type implemented in Python includes the following fields:

[0072] @dataclass;

[0073] class SOME / IPSdHeader:

[0074] SOME / IP_header:

[0075] SOME / IPHeader

[0076] reboot_flag: bool

[0077] unicast_flag: bool

[0078] length_entries: int

[0079] length_options: int

[0080] entries_array:List[SdEntry]

[0081] options_array:List[SdIPV4EndpointOption];

[0082] It should be noted that the SOME / IP-SD protocol header content has no fixed length and mainly includes the following fields:

[0083] Message Length: 4 bytes, indicating the length of the entire message (including the header).

[0084] Request ID: 4 bytes, consisting of a service identifier (Service ID) and an instance identifier (Instance ID).

[0085] Protocol Version: 1 byte, indicating the protocol version.

[0086] Interface Version: 1 byte, indicating the interface version.

[0087] Message Type: 1 byte, indicating the message type (such as discovery request, discovery response, subscription request, subscription response, etc.).

[0088] Return Code: 1 byte, indicating the return code (such as success, error, etc.).

[0089] Options Length: 4 bytes, indicating the total length of the options field.

[0090] Reserved field: 4 bytes, usually reserved and unused.

[0091] Options field: variable length, contains option information related to service discovery, such as service name, provider information, etc. Includes Entries Array and Options Array information.

[0092] The Entry data model described in the SOME / IP-SD protocol header includes the following fields:

[0093] @dataclass

[0094] class SdEntry:

[0095] type: Enum

[0096] index_first_option: int

[0097] index_second_option: int

[0098] num_options_1: int

[0099] num_options_2: int

[0100] service_id: int

[0101] instance_id: int

[0102] major_version: intttl: int;

[0103] The detailed description of the above Entries Array is as follows:

[0104] In the SOME / IP-SD (Service Discovery) protocol, Entries Array is an array containing multiple entries, each of which describes the information of a service or event. The length of each entry is fixed, usually 16 bytes.

[0105] Each Entry contains the following fields:

[0106] Service ID: 2 bytes, indicating the unique identifier of the service.

[0107] Instance ID: 2 bytes, indicating the unique identifier of the service instance.

[0108] Major Version: 1 byte, indicating the major version number of the service.

[0109] TTL (Time To Live): 4 bytes, indicating the validity period of the service (in seconds).

[0110] Options Length: 4 bytes, indicating the total length of the option field.

[0111] Flags: 1 byte, indicating some flags, such as whether it is subscribing, whether it has been provided, etc.

[0112] Reserved: 2 bytes, reserved field, usually not used.

[0113] The byte layout of each Entry is as follows:

[0114] |Service ID(2bytes)|Instance ID(2bytes)|Major Version(1byte)|TTL(4bytes)|

[0115] |Options Length(4bytes)|Flags(1byte)|Reserved(2bytes)|.

[0116] The Option data model described in the above SOME / IP-SD protocol header includes the following fields:

[0117] @dataclass

[0118] class SdIPV4EndpointOption:

[0119] length: int

[0120] type: Enum

[0121] flag: bool

[0122] ipv4_address:String

[0123] protocol: intport: int.

[0124] The detailed description of Options Array is as follows:

[0125] In the SOME / IP-SD (Service Discovery) protocol, Options Array is an array containing multiple options, each of which is used to carry additional service discovery information. The length of each option is not fixed, but variable, and the specific length depends on the type and content of the option.

[0126] Each Option contains the following fields:

[0127] Option Type: 2 bytes, indicating the option type.

[0128] Option Length: 2 bytes, indicating the length of the option data.

[0129] Option Data: Variable length. The specific length is determined by the Option Length field and contains the specific data of the option.

[0130] The byte layout of each Option is as follows:

[0131] |Option Type(2bytes)|Option Length(2bytes)|Option Data(variablelength)|.

[0132] In the embodiment of the present invention, the inventor has determined from the above fields that the second protocol header field that contributes to the location of the communication problem includes: a Message Type field for determining the current message type, a Protocol Version field and an Interface Version field for matching versions, an Entries Array array for characterizing the correctness of the server publishing process and the client subscription process, and an OptionsArray field for characterizing the node configuration information of the server and the client;

[0133] The Entries Array array includes a Type field for characterizing the completion status of the service discovery and subscription process, a Service ID field for characterizing service configuration information, an Instance ID field, a Major Version field, a Minor Version field, and a TTL (Time To Live) field.

[0134] In some embodiments, step S106 of analyzing the communication problem based on the second protocol header field may also be implemented by the following steps, specifically including:

[0135] Step 3.1), if the message type is service discovery, determine the second protocol header field according to the protocol header in the SOME / IP communication protocol corresponding to the service discovery.

[0136] Here, it can be understood that the second protocol header field is captured from the data packet of the service discovery message type.

[0137] It should be noted that the current step can further parse the data packet file, that is, by parsing the data packet to obtain message data, each field of the message can be obtained, and the second protocol header field can be extracted therefrom.

[0138] Step 3.2) Compare the fields in the second protocol header used to represent the service configuration information and the node configuration information with the standard configuration fields corresponding to the message type of service discovery to determine whether there is a communication problem with abnormal configuration between the current vehicle application processes.

[0139] On the basis of the foregoing embodiments, it is possible to know the various message fields corresponding to the data packet, and then know which standard configuration field the message corresponds to; by comparing the service configuration information and node configuration information of the message, as well as the corresponding standard configuration fields, it is possible to know whether the message has a configuration error; if the service configuration information and node configuration information of the message, as well as the corresponding standard configuration fields, are inconsistent, then there is a configuration error in the message, and at this time, the communication anomaly between the application processes (server and client) of the current vehicle is identified as being caused by a configuration error.

[0140] Among them, the Options Array field used to represent the node configuration information of the server and the client is actually an array; the fields in the Entries Array used to represent the service configuration information include the Service ID field, the Instance ID field, the Major Version field, the Minor Version field, and the TTL (Time To Live) field; by comparing the consistency of the above fields with the standard configuration fields, it is determined whether there is a configuration error.

[0141] Step 3.3), based on the content of the type field in the second protocol header, determine whether there is a communication problem between the current vehicle application processes such as server publishing exceptions and / or client subscription exceptions.

[0142] Here, the correct contents of the Type field include: 01: Offerservice; 06: Subscribe; 07: SubscribeAck;

[0143] If the server sends Type fields 01 and 07, and the client sends Type field 06, it is considered that the server publishes normally and the client subscribes normally;

[0144] If the server sends Type fields 01 and 07, and the client does not send Type field 06 or sends a Type field other than 06, it is considered that the server publishes normally and the client subscribes abnormally;

[0145] If the server fails to send both Type field 01 and Type field 07, and the client sends Type field 06, it is considered that the server publishes abnormally and the client subscribes normally;

[0146] If the server fails to send both Type field 01 and Type field 07, and the client does not send Type field 06 or sends a Type field other than 06, it is considered that the server publishes abnormally and the client subscribes abnormally.

[0147] At this time, based on the above situation, the communication anomaly between the application processes (server and client) of the current vehicle can be identified as caused by the server publishing anomaly and / or the client subscription anomaly.

[0148] In actual applications, if an application cannot find the service it needs (such as weather update service) after it is started, that is, it cannot discover the service, it may be because the service provider does not publish the service correctly, or the service requester does not subscribe to the service correctly.

[0149] The second protocol field in the service discovery protocol header SOME / IP-SD can be checked:

[0150] Message Type: Checks whether the current message type is Offer Service, Subscribe Eventgroup, Subscribe Eventgroup Ack, or other types of messages.

[0151] Protocol Version and Interface Version: Ensure that the versions match by comparing the consistency of the two fields.

[0152] Entries Array: Confirm whether the service discovery and client subscription processes are completed based on the Type field in the array; for example, 01: Offerservice; 06: Subscribe; 07: SubscribeAck.

[0153] Service ID, Instance ID, Major Version, Minor Version, TTL (Time To Live): Verify whether the contents of these fields are consistent with the preset standard configuration fields to confirm whether the service configuration information is correct during service discovery.

[0154] Options Array: Verify whether the node configuration information (such as IP information, port information, etc.) of the service provider (server) and service requester (client) is consistent with the preset standard configuration fields. This is to confirm whether the node configuration information of the service provider and service requester is correct and whether they can communicate normally.

[0155] As an optional embodiment, if the analysis of the second protocol header field in the aforementioned step S106 is normal, but there is a communication anomaly between the application processes (server and client) of the current vehicle, it may be considered to verify whether the service discovery message is lost or not delivered due to a network configuration problem, that is, a firewall or other network device blocks the transmission of the service discovery message, which in turn causes a communication anomaly between the application processes (server and client) of the current vehicle.

[0156] In some embodiments, the data model of the SOME / IP protocol header of the service communication message type implemented based on Python is as follows:

[0157] @dataclass

[0158] class SOME / IPHeader:

[0159] service_id: int

[0160] method_id: int

[0161] length: int

[0162] client_id: int

[0163] session_id: int

[0164] protocol_version: int

[0165] interface_version: int

[0166] message_type: int

[0167] return_code: int

[0168] The above SOME / IP protocol header content has a fixed length of 16 bytes and mainly includes the following fields:

[0169] Message Length: 4 bytes, indicating the length of the entire message (including the header).

[0170] Request ID: 4 bytes, consisting of a service identifier (Service ID) and a method identifier (Method ID).

[0171] Protocol Version: 1 byte, indicating the protocol version.

[0172] Interface Version: 1 byte, indicating the interface version.

[0173] Message Type: 1 byte, indicating the message type (such as request, response, event, etc.).

[0174] Return Code: 1 byte, indicating the return code (such as success, error, etc.).

[0175] Reserved field: 4 bytes, usually reserved and unused.

[0176] In the embodiment of the present invention, the inventor has determined, through research, from the above fields that a third protocol header field contributes to the location of the communication problem. The third protocol header field includes:

[0177] The Protocol Version field and Interface Version field are used to match the version, the Request ID field and Message Length field are used to represent the configuration information requested by the client, and the Message Type field and Return Code field are used to represent the processing status of the server.

[0178] Based on the above embodiment, determining the communication problem between vehicle application processes through the third protocol header field is implemented by step S108, including:

[0179] Step 4.1), if the message type is service communication, determine the third protocol header field according to the protocol header in the SOME / IP communication protocol corresponding to the service communication.

[0180] Here, it can be understood that the third protocol header field is captured from the data packet of the service communication message type.

[0181] It should be noted that the current step can further parse the data packet file, that is, by parsing the data packet to obtain message data, each field of the message can be obtained, and the third protocol header field can be extracted therefrom.

[0182] Step 4.2) Compare the configuration information used to characterize the client request in the third protocol header with the standard configuration information of the client request corresponding to the message type of the service communication to determine whether there is a communication problem of abnormal client request between the current vehicle application processes.

[0183] On the basis of the foregoing embodiments, it is possible to know the various message fields corresponding to the data packet, and then know which standard configuration field the message corresponds to; by comparing the configuration information requested by the client of the message and the corresponding standard configuration field, it is possible to know whether the message has a configuration error; if the configuration information requested by the client of the message and the corresponding standard configuration field are inconsistent, then there is a configuration error in the message, and at this time the communication anomaly between the application processes (server and client) of the current vehicle is identified as being caused by a configuration error.

[0184] The configuration information used to characterize the client request includes a Request ID field and a Message Length field.

[0185] Step 4.3), based on the content of the Message Type field in the third protocol header, determine whether there is a communication problem between the current vehicle application processes that causes the server to handle the exception.

[0186] Here, the content of the Message Type field includes: 00: request that requires a response; 01: request that does not require a response; 0x80: correct feedback; 0x81: error feedback; 0x82 subscription event push;

[0187] If the server sends the Message Type field 00 but responds with 0x81, or has no response, there is a processing exception on the server. In this case, the processing exception on the server is identified as the cause of the communication exception between the application processes (server and client) of the current vehicle.

[0188] Step 4.4), if there is a server-side processing exception, the type of server-side processing exception existing between the current vehicle application processes is determined based on the content of the Return Code field in the third protocol header.

[0189] The Return Code includes: 0x04E: known service ID and method ID, application is not running; 0x90: deserialization error; 0x0a: message type error, an unexpected message type is received;

[0190] In actual applications, if the client attempts to call a service on the server, but the server fails to receive a response successfully, that is, service communication cannot be achieved, it may be because the server does not process the request correctly, or the client calls the request incorrectly.

[0191] The third protocol field in the service communication protocol header SOME / IP can be checked:

[0192] Message ID (Method ID or Event ID): Confirm whether the method ID is correct.

[0193] Message Type: used to confirm whether the request is sent successfully, whether a corresponding response is required, and whether the response is successful.

[0194] Return Code: If there is a response, check what error the return code indicates.

[0195] Message Length and Request ID (message ID and service ID): Determine whether the configuration information requested by the client is incorrect.

[0196] As an optional embodiment, if the analysis of the third protocol header field in the aforementioned step S108 is normal, but there is a communication anomaly between the application processes (server and client) of the current vehicle, it may be considered to verify whether the loss of the service communication request or response is caused by a network configuration problem, that is, a firewall or other network device blocks the transmission of the service communication request, which in turn causes a communication anomaly between the application processes (server and client) of the current vehicle.

[0197] In some embodiments, the present invention further includes:

[0198] Step 5.1) converts the protocol header content corresponding to the data packet from bytecode to a readable JSON structure, which can monitor the communication status of the specified service instance between processes in real time to help developers and testers troubleshoot communication problems, greatly improving the efficiency of development and debugging.

[0199] The present invention provides a method for determining communication problems between vehicle application processes. The communication messages between SOME / IP service instances are captured by a packet capture tool, and the protocol header related information is extracted using Python language to determine the message type. Based on the message type, the SOME / IP protocol header content or the SOME / IP-SD protocol header content is extracted using Python language, and the communication status of the service instance specified between processes can be monitored in real time. The protocol header content can also be converted from bytecode to a readable json structure, which helps developers and testers eliminate communication problems and greatly improves the work efficiency of development and debugging.

[0200] In some embodiments, Figure 2 As shown, the embodiment of the present invention further provides a device 200 for determining a communication problem between vehicle application processes, comprising:

[0201] An acquisition module 201 acquires abnormal communication data packets transmitted between current vehicle application processes;

[0202] The first determination module 202 determines the message type of the SOME / IP communication protocol based on the first protocol header field corresponding to the abnormal communication data packet; wherein the message type includes service discovery and service communication;

[0203] The second determination module 203, if the message type is service discovery, determines the communication problem between the current vehicle application processes according to the second protocol header field corresponding to the abnormal communication data packet; wherein the second protocol header field is used to represent the publishing status of the server and the subscription status of the client;

[0204] The third determination module 204, if the message type is service communication, determines the communication problem between the current vehicle application processes according to the third protocol header field corresponding to the abnormal communication data packet; wherein the third protocol header field is used to characterize the client's request status and the server's processing status of the request sent by the client.

[0205] Furthermore, the second protocol header field includes:

[0206] The Message Type field is used to determine the current message type, the ProtocolVersion field and the Interface Version field are used to match the version, the Entries Array array is used to characterize the correctness of the server publishing process and the client subscription process, and the Options Array field is used to characterize the node configuration information of the server and the client;

[0207] The Entries Array array includes a Type field for characterizing the completion status of the service discovery and subscription process, a Service ID field for characterizing service configuration information, an Instance ID field, a Major Version field, a Minor Version field, and a TTL (Time To Live) field.

[0208] In some embodiments, the second determination module 203 is specifically used to, if the message type is service discovery, determine the second protocol header field according to the protocol header in the SOME / IP communication protocol corresponding to the service discovery; compare the field in the second protocol header used to characterize the service configuration information and the node configuration information with the standard configuration field corresponding to the message type of the service discovery to determine whether there is a communication problem with abnormal configuration between the current vehicle application processes; based on the content of the type field in the second protocol header, determine whether there is a communication problem with server publishing abnormality and / or client subscription abnormality between the current vehicle application processes.

[0209] Furthermore, the third protocol header field includes:

[0210] The Protocol Version field and Interface Version field are used to match the version, the Request ID field and Message Length field are used to represent the configuration information requested by the client, and the Message Type field and Return Code field are used to represent the processing status of the server.

[0211] In some embodiments, the third determination module 204 is specifically used to, if the message type is service communication, determine the third protocol header field according to the protocol header in the SOME / IP communication protocol corresponding to the service communication; compare the configuration information used to characterize the client request in the third protocol header with the standard configuration information of the client request corresponding to the message type of the service communication to determine whether there is a communication problem of client request exception between the current vehicle application processes; based on the content of the Message Type field in the third protocol header, determine whether there is a communication problem of server processing exception between the current vehicle application processes; if there is a server processing exception, determine the type of server processing exception between the current vehicle application processes based on the content of the Return Code field in the third protocol header.

[0212] In some embodiments, the first determination module 202 is specifically used to determine the first protocol header field of the SOME / IP communication protocol based on the abnormal communication data packet; wherein the first protocol header field includes Service-ID, Method-ID and Client-ID; if the first protocol header fields are all fixed values, the message type of the SOME / IP communication protocol is determined to be service discovery; if the first protocol header field has a variable value, the message type of the SOME / IP communication protocol is determined to be service communication.

[0213] In some embodiments, the acquisition module 201 is specifically used to capture the communication messages between the current vehicle application processes through a preset packet capture tool to generate an abnormal communication data packet.

[0214] Figure 3 Schematic diagram of the hardware architecture of the electronic device 300 provided in an embodiment of the present invention. Figure 3 As shown, the electronic device 300 includes: a machine-readable storage medium 301 and a processor 302, and may also include a non-volatile storage medium 303, a communication interface 304 and a bus 305; wherein the machine-readable storage medium 301, the processor 302, the non-volatile storage medium 303 and the communication interface 304 complete mutual communication through the bus 305. The processor 302 can execute the method for determining the communication problem between vehicle application processes described in the above embodiment by reading and executing the machine-executable instructions for determining the communication problem between vehicle application processes in the machine-readable storage medium 301.

[0215] The machine-readable storage medium mentioned in this article can be any electronic, magnetic, optical or other physical storage device that can contain or store information, such as executable instructions, data, etc. For example, the machine-readable storage medium can be: RAM (Radom Access Memory), volatile memory, non-volatile memory, flash memory, storage drive (such as hard disk drive), any type of storage disk (such as CD, DVD, etc.), or similar storage medium, or a combination thereof.

[0216] The non-volatile medium may be a non-volatile memory, a flash memory, a storage drive (such as a hard drive), any type of storage disk (such as a CD, DVD, etc.), or a similar non-volatile storage medium, or a combination thereof.

[0217] It can be understood that the specific operation methods of each functional module in this embodiment can refer to the detailed description of the corresponding steps in the above method embodiment, and will not be repeated here.

[0218] The computer-readable storage medium provided in the embodiment of the present invention stores a computer program. When the computer program code is executed, the method for determining the communication problem between vehicle application processes described in any of the above embodiments can be implemented. The specific implementation can be found in the method embodiment, which will not be repeated here.

[0219] Those skilled in the art can clearly understand that, for the convenience and brevity of description, the specific working process of the system and device described above can refer to the corresponding process in the aforementioned method embodiment, and will not be repeated here.

[0220] In addition, in the description of the embodiments of the present invention, unless otherwise clearly specified and limited, the terms "installed", "connected", and "connected" should be understood in a broad sense, for example, it can be a fixed connection, a detachable connection, or an integral connection; it can be a mechanical connection or an electrical connection; it can be a direct connection or an indirect connection through an intermediate medium, or it can be the internal communication of two components. For ordinary technicians in this field, the specific meanings of the above terms in the present invention can be understood according to specific circumstances.

[0221] In the description of the present invention, it should be noted that the terms "center", "upper", "lower", "left", "right", "vertical", "horizontal", "inner", "outer", etc., indicating the orientation or positional relationship, are based on the orientation or positional relationship shown in the drawings, and are only for the convenience of describing the present invention and simplifying the description, rather than indicating or implying that the device or element referred to must have a specific orientation, be constructed and operated in a specific orientation, and therefore cannot be understood as limiting the present invention. In addition, the terms "first", "second", and "third" are used for descriptive purposes only, and cannot be understood as indicating or implying relative importance.

[0222] Finally, it should be noted that the above-described embodiments are only specific implementation methods of the present invention, which are used to illustrate the technical solutions of the present invention rather than to limit them. The protection scope of the present invention is not limited thereto. Although the present invention has been described in detail with reference to the aforementioned embodiments, those of ordinary skill in the art should understand that any technician familiar with the technical field can still modify the technical solutions recorded in the aforementioned embodiments within the technical scope disclosed by the present invention, or can easily conceive of changes, or make equivalent replacements for some of the technical features therein. Such modifications, changes or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the embodiments of the present invention, and should all be covered within the protection scope of the present invention.

Claims

1. A method for determining a communication problem between vehicle application processes, characterized in that: include: Obtain abnormal communication data packets transmitted between current vehicle application processes; Determine the message type of the SOME / IP communication protocol based on the first protocol header field corresponding to the abnormal communication data packet; wherein the message type includes service discovery and service communication; If the message type is service discovery, the communication problem between the current vehicle application processes is determined according to the second protocol header field corresponding to the abnormal communication data packet; wherein the second protocol header field is used to represent the publishing status of the server and the subscription status of the client; If the message type is service communication, the communication problem between the current vehicle application processes is determined based on the third protocol header field corresponding to the abnormal communication data packet; wherein the third protocol header field is used to characterize the client's request status and the server's processing status of the request sent by the client.

2. The method according to claim 1, characterized in that The second protocol header field includes: The Message Type field is used to determine the current message type, the Protocol Version field and the Interface Version field are used to match the version, the Entries Array array is used to characterize the correctness of the server publishing process and the client subscription process, and the Options Array field is used to characterize the node configuration information of the server and the client; The Entries Array array includes a Type field for characterizing the completion status of the service discovery and subscription process, a Service ID field for characterizing service configuration information, an Instance ID field, a Major Version field, a MinorVersion field, and a TTL (Time To Live) field.

3. The method according to claim 2, characterized in that If the message type is service discovery, the step of determining the communication problem between the current vehicle application processes according to the second protocol header field corresponding to the abnormal communication data packet includes: If the message type is service discovery, determining a second protocol header field according to a protocol header in a SOME / IP communication protocol corresponding to the service discovery; Compare the fields in the second protocol header used to represent the service configuration information and the node configuration information with the standard configuration fields corresponding to the message type of the service discovery, and determine whether there is a communication problem with abnormal configuration between the current vehicle application processes; Based on the content of the type field in the second protocol header, determine whether there is a communication problem between the current vehicle application processes, such as a server publishing exception and / or a client subscription exception.

4. The method according to claim 1, characterized in that The third protocol header field includes: The Protocol Version field and Interface Version field are used to match the version, the Request ID field and Message Length field are used to represent the configuration information requested by the client, and the Message Type field and Return Code field are used to represent the processing status of the server.

5. The method according to claim 4, characterized in that If the message type is service communication, the step of determining the communication problem between the current vehicle application processes according to the third protocol header field corresponding to the abnormal communication data packet includes: If the message type is service communication, determining a third protocol header field according to a protocol header in a SOME / IP communication protocol corresponding to the service communication; Compare the configuration information used to characterize the client request in the third protocol header with the standard configuration information of the client request corresponding to the message type of the service communication, and determine whether there is a communication problem of abnormal client request between the current vehicle application processes; Based on the content of the Message Type field in the third protocol header, determining whether there is a communication problem between the current vehicle application processes caused by the server processing exception; If there is a server-side processing exception, the type of server-side processing exception existing between the current vehicle application processes is determined based on the content of the Return Code field in the third protocol header.

6. The method according to claim 1, characterized in that The step of determining the message type of the SOME / IP communication protocol based on the first protocol header field corresponding to the abnormal communication data packet includes: Based on the abnormal communication data packet, determining a first protocol header field of the SOME / IP communication protocol; wherein the first protocol header field includes a Service-ID, a Method-ID and a Client-ID; If the first protocol header fields are all fixed values, the message type of the SOME / IP communication protocol is determined to be service discovery; If there is a value change in the first protocol header field, the message type of the SOME / IP communication protocol is determined to be service communication.

7. The method according to claim 1, characterized in that The steps of obtaining abnormal communication data packets transmitted between current vehicle application processes include: The communication messages between the current vehicle application processes are captured through the preset packet capture tool to generate abnormal communication data packets.

8. A device for determining communication problems between vehicle application processes, characterized in that: include: An acquisition module is used to acquire abnormal communication data packets transmitted between current vehicle application processes; A first determination module determines a message type of the SOME / IP communication protocol based on a first protocol header field corresponding to the abnormal communication data packet; wherein the message type includes service discovery and service communication; A second determination module, if the message type is service discovery, determines the communication problem between the current vehicle application processes according to the second protocol header field corresponding to the abnormal communication data packet; wherein the second protocol header field is used to characterize the publishing status of the server and the subscription status of the client; The third determination module determines the communication problem between the current vehicle application processes based on the third protocol header field corresponding to the abnormal communication data packet if the message type is service communication; wherein the third protocol header field is used to characterize the client's request status and the server's processing status of the request sent by the client.

9. An electronic device comprising a memory and a processor, wherein the memory stores a computer program that can be run on the processor, characterized in that: When the processor executes the computer program, the steps of the method according to any one of claims 1 to 7 are implemented.

10. A machine-readable storage medium, characterized in that: The machine-readable storage medium stores machine-executable instructions. When the machine-executable instructions are called and executed by a processor, the machine-executable instructions prompt the processor to implement the steps of the method described in any one of claims 1 to 7.

Images