Debugging method, apparatus and system

Abstract

The application provides a debugging method, device and system, the method comprising: obtaining initial parameters input by a user and a selected network port, the initial parameters comprising debugging parameters simulated by a debugging tool and service parameters provided in a first message, the debugging parameters comprising a simulated physical address, the service parameters comprising a session number of service discovery and an identification number of an IP, and the network port being a network port connected to a device under test by a server; executing a message sending process and a message monitoring process in parallel according to the initial parameters and the network port; the message sending process comprising: sending the first message to the device under test according to the initial parameters and at a preset period; the message monitoring process comprising: monitoring the network port in real time; when the network port is found to have received a second message sent by the device under test, analyzing the second message and feeding back response information of the second message to the device under test. Through the above method, SOME / IP early-stage debugging can be performed when a test board is connected to a computer through a network port.

Description

Technical Field

[0001] This invention relates to the field of computer technology, and in particular to a debugging method, apparatus and system. Background Technology

[0002] With the rapid development of automotive Ethernet, an automotive network architecture based on the SOME / IP (Scalable service-oriented middleware over IP) protocol has been formed.

[0003] In existing technologies, SOME / IP debugging methods include: 1. Connecting the computer's network port directly to the development board and using packet capture tools to capture and analyze Ethernet frames. However, this method can only capture and analyze Ethernet frames and cannot send Ethernet packets, thus failing to complete the initial debugging work. 2. Connecting the computer's USB (Universal Serial Bus) port to the VN5610, and connecting the development board to the VN5610's network port, using CANOE (CAN openenvironment) for debugging. However, this method requires the support of both the VN5610 and CANOE environments.

[0004] Therefore, how to perform initial debugging of SOME / IP on a computer by connecting the test board via the network port has become a technical problem that urgently needs to be solved by those skilled in the art. Summary of the Invention

[0005] In view of this, embodiments of the present invention provide a debugging method, apparatus and system to enable preliminary debugging of SOME / IP when the test board is connected to a computer via a network port.

[0006] To achieve the above objectives, the embodiments of the present invention provide the following technical solutions:

[0007] The first aspect of this invention discloses a debugging method applicable to a server, wherein the server is equipped with debugging tools, and the method includes:

[0008] The system obtains the initial parameters and the selected network port input by the user. The initial parameters include the debugging parameters simulated by the debugging tool and the service parameters provided in the first message. The debugging parameters include the simulated physical address. The service parameters include the session number of service discovery and the identifier of Internet Protocol IP. The network port is the network port through which the server connects to the device being debugged.

[0009] Based on the initial parameters and the network interface, the main process of sending packets and the process of listening packets are executed in parallel.

[0010] The main process for sending messages includes:

[0011] According to the initial parameters, the first message is sent to the device under test according to a preset period. Each time the first message is sent, the session number and the identifier number are incremented by one.

[0012] The message monitoring process includes:

[0013] Real-time monitoring of the network port;

[0014] When the network port receives the second message sent by the device under test, it parses the second message and feeds back the response information of the second message to the device under test.

[0015] Optionally, when the network port receives the second packet sent by the device under test, parsing the second packet and feeding back the response information of the second packet to the device under test includes:

[0016] When the network port receives the second message sent by the device under test, it parses the second message to obtain the target physical address of the device under test;

[0017] Based on the type of the target physical address, the response information of the second message is fed back to the device under debugging. The type of the target physical address includes multicast or broadcast addresses and simulated physical addresses.

[0018] Optionally, the step of feeding back the response information of the second message to the device under debugging according to the type of the target physical address includes:

[0019] If the target physical address is the multicast or broadcast address, determine whether the second message is a third message;

[0020] If so, based on the multicast or broadcast address, generate the response information of the third message, and feed back the response information of the third message to the device under debugging, and increment the identifier number by one.

[0021] Optional, also includes:

[0022] If not, determine whether the second message is the first message;

[0023] If so, there is no need to reply to the device under debugging with the response information of the second message, and the process returns to the step of real-time monitoring of the network port;

[0024] If not, return directly to the step of performing real-time monitoring of the network port.

[0025] Optionally, the step of feeding back the response information of the second message to the device under debugging according to the type of the target physical address includes:

[0026] If the target physical address is the simulated physical address, determine whether the second packet is the fourth packet;

[0027] If so, parse the fourth message to obtain the subscription service item information;

[0028] Based on the subscription service item information, the response information of the fourth message is generated and fed back to the device under debugging, and the session number and the identifier number are incremented by one.

[0029] Optional, also includes:

[0030] If not, determine whether the second message is the fifth message;

[0031] If so, parse the fifth message to obtain the fifth message information;

[0032] Based on the information in the fifth message, a response message for the fifth message is generated and fed back to the device under debugging. The session number and the identifier number are incremented by one.

[0033] Optionally, after feeding back the response information to the device under debugging, the method further includes:

[0034] Return to the step of performing real-time monitoring of the network interface.

[0035] Optional, also includes:

[0036] If the network port does not receive the second message sent by the device under test, return to the step of real-time monitoring of the network port.

[0037] A second aspect of this invention discloses a debugging apparatus suitable for a server, wherein the server is equipped with debugging tools, and the apparatus includes:

[0038] The acquisition module is used to acquire the initial parameters and the selected network port input by the user. The initial parameters include the debugging parameters simulated by the debugging tool and the service parameters provided in the first message. The debugging parameters include the simulated physical address. The service parameters include the session number of service discovery and the identifier of Internet Protocol IP. The network port is the network port through which the server is connected to the device being debugged.

[0039] The message sending and listening module is used to execute the main message sending process and the message listening process in parallel according to the initial parameters and the network interface.

[0040] The message sending and listening module for sending messages includes:

[0041] The sending unit is configured to send the first message to the device under test according to the initial parameters and a preset period, wherein the session number and the identifier number are incremented by one each time the first message is sent;

[0042] The message sending and listening module for message monitoring includes:

[0043] A monitoring unit is used to monitor the network port in real time;

[0044] The parsing and feedback unit is used to parse the second message when the network port receives the second message sent by the device under test, and to feed back the response information of the second message to the device under test.

[0045] A third aspect of this invention discloses a debugging system, the system comprising: a server and a client, the server being equipped with debugging tools, and the client being a device being debugged;

[0046] The server is used to obtain initial parameters and a selected network port input by the user. The initial parameters include debugging parameters simulated by the debugging tool and service parameters provided in the first packet. The debugging parameters include a simulated physical address, and the service parameters include a session number for service discovery and an Internet Protocol (IP) identifier. The network port is the network port through which the server connects to the device under test. Based on the initial parameters and the network port, the server executes a main packet sending process and a packet listening process in parallel. The packet sending process includes: sending the first packet to the device under test according to the initial parameters and a preset period, incrementing the session number and identifier number each time the first packet is sent; the packet listening process includes: monitoring the network port in real time; when the network port receives a second packet sent by the device under test, parsing the second packet, and feeding back the response information of the second packet to the device under test.

[0047] The client is configured to receive the first message sent by the server, send a second message to the server, and receive response information from the server regarding the second message.

[0048] Based on the above embodiments of the present invention, a debugging method, apparatus, and system are provided. The method includes: acquiring initial parameters input by a user and a selected network port, wherein the initial parameters include debugging parameters simulated by the debugging tool and service parameters provided in a first message, the debugging parameters include a simulated physical address, and the service parameters include a session number for service discovery and an Internet Protocol (IP) identifier, and the network port is the network port connecting the server and the device under debugging; according to the initial parameters and the network port, a message sending process and a message listening process are executed in parallel; the message sending process includes: according to the initial parameters, sending the first message to the device under debugging according to a preset period, incrementing the session number and identifier by one each time the first message is sent; the message listening process includes: monitoring the network port in real time; when the network port receives a second message sent by the device under debugging, parsing the second message, and feeding back the response information of the second message to the device under debugging. In this solution, based on the acquired initial parameters and network port, the first message is sent periodically, while the network port is monitored. The second message received is parsed and responded to, thereby enabling SOME / IP initial debugging to be performed when the test board is connected to the computer via the network port. Attached Figure Description

[0049] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on the provided drawings without creative effort.

[0050] Figure 1 A flowchart illustrating a debugging method provided in an embodiment of the present invention;

[0051] Figure 2 A schematic diagram of a process for parsing a second message provided in an embodiment of the present invention;

[0052] Figure 3 This is a schematic diagram of a process for feeding back the response information of a second message to the device under debugging based on the type of the target physical address, as provided in an embodiment of the present invention.

[0053] Figure 4 A design block diagram of a host computer for SOME / IP early debugging is provided in this embodiment of the invention;

[0054] Figure 5 This is a schematic diagram of a debugging device provided in an embodiment of the present invention. Detailed Implementation

[0055] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0056] In this application, the terms "comprising," "including," or any other variations thereof are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0057] The terms "first," "second," etc. (if present) in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such use of data can be interchanged where appropriate so that the embodiments described herein can be implemented in a sequence other than that illustrated or described herein.

[0058] As the background technology indicates, existing SOME / IP debugging methods do not allow for initial SOME / IP debugging on a computer connected to the test board via a network port.

[0059] Therefore, embodiments of the present invention provide a debugging method, apparatus, and system. In this solution, based on the acquired initial parameters and network port, a first message is periodically sent, while the network port is monitored. The monitored second message is parsed and responded to, thereby enabling SOME / IP pre-debugging when the test board is connected to the computer via the network port.

[0060] like Figure 1 The diagram shown is a flowchart of a debugging method provided in an embodiment of the present invention, which is applicable to the server side.

[0061] It should be noted that the server is equipped with debugging tools.

[0062] In this embodiment of the invention, the server is a computer.

[0063] The debugging tool is a host computer based on Python, designed using Scapy's packet assembly, packet sending, and listening APIs (Application Programming Interface) for early-stage debugging of SOME / IP. In other words, the debugging tool is a Python-based early-stage debugging tool for SOME / IP.

[0064] This debugging method mainly includes the following steps:

[0065] Step S101: Obtain the initial parameters and selected network port input by the user.

[0066] In step S101, the initial parameters include the debugging parameters simulated by the debugging tool and the service parameters provided in the first message.

[0067] The debugging parameters include the simulated physical address. The simulated physical address is the MAC (Media Access Control) address.

[0068] The debugging parameters also include IP address (Internet Protocol Address), UDP (User Datagram Protocol) port number, and ARP (Address Resolution Protocol) response message, which are not limited in any way by this invention.

[0069] The first message is a SOME / IP-SD (Scalable service-Oriented Middleware over IP-Service Discovery) offer message.

[0070] The service parameters include the session number for service discovery and the identifier of the Internet Protocol (IP) IP address.

[0071] Service discovery is SOME / IP-SD.

[0072] The session number is SessionID.

[0073] In practical applications, the session number for service discovery, i.e., the SessionID of SOME / IP-SD, is assigned the value 0.

[0074] The identifier is called Identification.

[0075] In practical applications, the Internet Protocol (IP) identifier, or IP identification, is assigned a value of 0.

[0076] The network port is the interface through which the server connects to the device being debugged, i.e., the network card interface.

[0077] In the specific implementation step S101, the server is first connected to the device being debugged via a network cable. Then, the debugging tool is run, the user inputs the initial parameters, selects the network port on which the server is connected to the device being debugged, and clicks "open". The server then obtains the initial parameters input by the user and the selected network port.

[0078] In other words, first connect the development board of the device to be debugged to the computer's network port using a network cable. Then, open the debugging tool set on the computer, or in other words, run the host computer. After that, the user inputs the initial parameters, selects the network port on the computer connected to the device to be debugged, and clicks open. The debugging tool then obtains the initial parameters input by the user and the selected network port.

[0079] In this embodiment of the invention, after obtaining the initial parameters input by the user and the selected network interface, the main process of sending messages and the message listening process are executed in parallel according to the initial parameters and the network interface.

[0080] The main process for sending messages includes the following steps:

[0081] Step S102: Based on the initial parameters and according to the preset period, send the first message to the device under test.

[0082] In step S102, the session number and identifier number are incremented by one each time the first message is sent.

[0083] In the specific implementation step S102, the debugging tool periodically sends the first message according to the initial parameters obtained from the user input. That is, the debugging tool sends the first message to the device under debugging according to the initial parameters and a preset period. Each time the first message is sent, the session number and the identifier number are incremented by one.

[0084] In practical applications, the main thread is started to periodically send SOME / IP-SD Offer messages. After each transmission, the SessionID and Identification are incremented by 1, and this process continues throughout the entire operation of the host computer.

[0085] It should be noted that the initial parameters set in the service parameters provided in the SOME / IP-SD offer message are determined according to actual needs. For example, in the current Didi vehicle domain controller project, the main phase cycle time requirement is 1000ms.

[0086] The main phase cycle time requirement can be understood as sending SOME / IP-SD Offer messages according to the cycle time (1000ms) in the main message sending process. That is, SOME / IP-SD Offer messages are sent according to the preset cycle (1000ms) corresponding to the cycle. In other words, within the cycle range, SOME / IP-SD Offer messages are sent once every 1000ms. For example, if the cycle range is 10000ms, SOME / IP-SD Offer messages are sent once every 1000ms within these 10000ms.

[0087] The message monitoring process includes the following steps:

[0088] Step S103: Monitor the network port in real time.

[0089] In practical applications, a listening thread is started to monitor the network port selected by the user in real time.

[0090] Step S104: Determine whether the network port has received the second message sent by the device being debugged. If yes, proceed to step S105; otherwise, return to step S103.

[0091] In step S104, the second message is an Ethernet message.

[0092] In the specific implementation of step S104, it is determined whether the network port has received the second message sent by the device under test, that is, whether the network port has received the Ethernet message sent by the device under test. If yes, step S105 is executed. If no, it means that the message currently received is not the second message (Ethernet message) but other messages. At this time, it is necessary to return to continue real-time monitoring of the network port, and then return to execute step S103.

[0093] Step S105: Parse the second message and send the response information of the second message back to the device being debugged.

[0094] In the specific implementation of step S105, when it is determined that the network port has received the second message sent by the device under test, the second message is parsed to obtain the relevant data information of the second message, a response is made to the second message to obtain the response information of the second message, and the response information of the second message is fed back to the device under test. That is, when it is determined that the network port has received the Ethernet message sent by the device under test, the Ethernet message is parsed to obtain the relevant data information of the Ethernet message, a response is made to the Ethernet message to obtain the response information of the Ethernet message, and the response information of the Ethernet message is fed back to the device under test.

[0095] Optionally, step S105 involves parsing the second message and feeding back the response information of the second message to the device under test, such as... Figure 2The diagram shown illustrates a process for parsing a second message according to an embodiment of the present invention, mainly including the following steps:

[0096] Step S201: Parse the second message to obtain the target physical address of the device being debugged.

[0097] It should be noted that parsing the second message can yield relevant parameters of the device being debugged, such as the IP address of the device being debugged. The specific parameters obtained can be determined based on the actual situation of SOME / IP debugging in the early stages, and this application does not impose any limitations on them, all of which are within the protection scope of this application.

[0098] Step S202: Based on the type of the target physical address, send the response information of the second message back to the device being debugged.

[0099] In step S202, the type of the target physical address includes multicast or broadcast addresses and analog physical addresses.

[0100] Optionally, the process of executing step S202, which involves feeding back the response information of the second message to the device under debugging based on the type of the target physical address, can be as follows: Figure 3 As shown, the main steps include:

[0101] Step S301: Determine whether the target physical address is a multicast or broadcast address. If yes, proceed to step S302; otherwise, proceed to step S306.

[0102] In the specific implementation of step S301, it is determined whether the target physical address is a multicast or broadcast address. If yes, step S302 is executed; otherwise, it indicates that the target physical address is a simulated physical address, and step S306 is executed.

[0103] Step S302: Determine whether the second message is the third message. If yes, proceed to step S303; otherwise, proceed to step S304.

[0104] In step S302, the third message is an ARP message.

[0105] In the specific implementation of step S302, it is determined whether the second packet is a third packet, that is, whether the Ethernet packet is an ARP packet. If yes, step S303 is executed. If no, it means that the second packet is another packet, and it is necessary to determine which type of packet the second packet is, then step S304 is executed.

[0106] Step S303: Generate the response information of the third message according to the multicast or broadcast address, and feed back the response information of the third message to the device under test, incrementing the identifier number by one.

[0107] In the specific implementation of step S303, when it is determined that the second message is the third message, that is, when it is determined that the Ethernet message is an ARP message, the response information of the third message is generated according to the target physical address obtained by parsing above, that is, according to the multicast or broadcast address. The response information of the third message is fed back to the device under test, the identifier number is incremented by one, and then the process returns to step S103.

[0108] In other words, if the received Ethernet packet is an ARP packet, an ARP reply is performed, that is, an initially defined ARP response packet is sent, the Identification is incremented by 1, and then the process returns to step S103.

[0109] Step S304: Determine whether the second message is the first message. If yes, proceed to step S305; otherwise, return to step S103.

[0110] In the specific implementation of step S304, it is determined whether the second message is the first message, that is, whether the received Ethernet message is a SOME / IP-SD offer message. If yes, step S305 is executed; otherwise, the process returns to step S103.

[0111] Step S305: No need to reply to the device being debugged with the response information of the second message, and return to the step of performing real-time monitoring of the network interface.

[0112] In the specific implementation of step S305, if it is determined that the second message is the first message, that is, if it is determined that the Ethernet message is the SOME / IP-SD offer message, there is no need to respond to the SOME / IP-SD offer message, that is, there is no need to reply to the device under debugging with the response information of the second message. Then, return to the step of real-time monitoring of the network port, that is, return to continue to execute step S103.

[0113] Step S306: Determine whether the second message is the fourth message. If yes, proceed to step S307; otherwise, proceed to step S309.

[0114] In step S306, the fourth message is a SOME / IP-SD Subscribe message.

[0115] In the specific implementation of step S306, if the target physical address is determined to be a simulated physical address, it is determined whether the second packet is the fourth packet, that is, whether the Ethernet packet is a SOME / IP-SD Subscribe packet. If yes, step S307 is executed; if no, it means that the second packet is another packet, and it is necessary to determine which type of packet the second packet is, then step S309 is executed.

[0116] Step S307: Parse the fourth message to obtain the subscription service item information.

[0117] In the specific implementation of step S307, when it is determined that the second message is the fourth message, that is, when it is determined that the Ethernet message is the SOME / IP-SD Subscribe message, the subscribed service items in the fourth message are parsed, that is, the subscribed service items in the SOME / IP-SD Subscribe message are parsed to obtain the corresponding subscription service item information.

[0118] Step S308: Based on the subscription service item information, generate the response information of the fourth message and send the response information of the fourth message back to the device under debugging, incrementing the session number and the identifier number by one.

[0119] In the specific implementation of step S308, the response information of the fourth message is generated based on the parsed subscription service item information, and the response information of the fourth message is fed back to the device under test, that is, the response information of the SOME / IP-SDSubscribe message is generated and fed back to the device under test. The session number and the identifier number are incremented by one, and then the process returns to step S103.

[0120] In other words, if an Ethernet packet is received as a SOME / IP-SD Subscribe packet, the subscribed service item in the Subscribe packet is parsed, the corresponding SubscribeACK is replied with, the SessionID and Identification are incremented by 1, and then the process returns to step S103.

[0121] Step S309: Determine whether the second message is the fifth message. If yes, proceed to step S310; otherwise, return to step S103.

[0122] In step S309, the fifth message is a SOME / IP Request message.

[0123] In the specific implementation of step S309, it is determined whether the second message is the fifth message, that is, whether the Ethernet message is a SOME / IP Request message. If yes, step S310 is executed; if no, it means that the second message is another message, and then the process returns to step S103.

[0124] Step S310: Parse the fifth message to obtain the information of the fifth message.

[0125] In the specific implementation of step S310, when it is determined that the second message is the fifth message, that is, when it is determined that the Ethernet message is a SOME / IP Request message, the fifth message is parsed to obtain the corresponding fifth message information.

[0126] Step S311: Based on the information in the fifth message, generate the response information for the fifth message and send the response information back to the device under test, incrementing the session number and identifier number by one.

[0127] In the specific implementation of step S311, the response information of the fifth message is generated based on the parsed fifth message information, and the response information of the fifth message is fed back to the device under test, that is, the response information of the SOME / IP Request message is generated and fed back to the device under test. The session number and the identifier number are incremented by one, and then the process returns to step S103.

[0128] In other words, if an Ethernet packet is received as a SOME / IPRequest packet, the Request packet is parsed, the corresponding Responses are sent, the SessionID and Identification are incremented by 1, and then the process returns to step S103.

[0129] It should be noted that if the received Ethernet packet is another type of packet, ignore the received Ethernet packet here, and then return to step S103.

[0130] It should be noted that after completing the above steps, shut down the host computer, end all threads, that is, close the debugging tool, end debugging, and exit the program.

[0131] Based on the above description, it can be understood that as long as the development board is connected to the computer's network port, the initial parameters are entered into the host computer, the corresponding network port is selected and opened, the host computer can periodically send SOME / IP-SD Offer messages according to the design logic and initial parameters, while receiving and listening, parsing the received Ethernet messages and responding.

[0132] Based on the debugging method provided by the embodiments of the present invention, the first message is periodically sent according to the obtained initial parameters and network port, while the network port is monitored, and the monitored second message is parsed and responded to, thereby enabling SOME / IP preliminary debugging to be performed on the computer when connected to the test board through the network port.

[0133] To better understand the above explanation, as follows: Figure 4 The diagram shown is a design block diagram for the initial debugging of the host computer SOME / IP according to an embodiment of the present invention, which specifically includes the following steps:

[0134] Step S1: Run the host computer, configure and input the initial parameters.

[0135] The initial parameters include: the MAC address, IP address, UDP port number, ARP response message, service parameters provided in the SOME / IP-SD offer message, the SessionID of SOME / IP-SD set to 0, and the Identification of IP set to 0.

[0136] Step S2: Select the corresponding network port on the computer and turn on the network port.

[0137] Step S3: Start the main thread and periodically send SOME / IP-SD Offer messages. After each sending, increment SessionID and Identification by 1, i.e., SD.SessionID++, IP.Identification++, and resend the SOME / IP-SD Offer message after a preset delay.

[0138] It should be noted that step S3 is performed continuously throughout the entire operation of the host computer.

[0139] It should be noted that the specific value of the preset time can be determined based on the actual situation of SOME / IP's early debugging. This application does not limit it, and all such values ​​are within the scope of protection of this application.

[0140] In some embodiments, the preset time can be 0.2 seconds.

[0141] Step S4: Start a listening thread to listen to the network interface. In practice, this means listening to packets received by the network interface. When an Ethernet packet is received, proceed to step S5.

[0142] Step S5: Determine whether the target MAC address is a multicast / broadcast address. If the target MAC address is a multicast / broadcast address, execute steps S51 and S52 sequentially. If the target MAC address is not a multicast / broadcast address, proceed to step S6.

[0143] Step S51: Determine if the Ethernet packet is an ARP packet. If the Ethernet packet is an ARP packet, proceed to step S53 to send an ARP response reply, specifically by sending the initially defined ARP response packet, incrementing Identification by 1 (i.e., IP.Identification++), and then return to step S4. If the Ethernet packet is not an ARP packet, proceed to step S52.

[0144] Step S52: Determine whether the Ethernet packet is an Offer packet. If the Ethernet packet is an Offer packet (i.e., SOME / IP-SD Offer packet), execute step S54 to perform no response, i.e., Do nothing, and then return to step S4.

[0145] Step S6: Determine whether the target MAC address is a local address. If the target MAC address is a local address, that is, if the target MAC address is the simulated MAC address of the host computer's initial parameters, execute steps S61 and S62 in sequence.

[0146] Step S61: Determine if the Ethernet packet is a Subscribe packet. If the Ethernet packet is a Subscribe packet (i.e., a SOME / IP-SD Subscribe packet), proceed to step S63 to parse the Subscribe packet and reply with a SubscribeACK. Specifically, parse the subscribed service item in the Subscribe packet and reply with the corresponding SubscribeACK. At the same time, increment SessionID and Identification by 1, i.e., SD.SessionID++ and IP.Identification++. Then, return to step S4. If the Ethernet packet is not a Subscribe packet, proceed to step S62.

[0147] Step S62: Determine whether the Ethernet packet is a Request packet. If the Ethernet packet is a Request packet (i.e., SOME / IP Request packet), execute step S64 to parse the Request packet, reply with the corresponding Responses, increment SessionID and Identification by 1, i.e., SD.SessionID++, IP.Identification++, and then return to step S4.

[0148] If the Ethernet packet is another type of packet, ignore it and return to step S4.

[0149] Step S7: Close the program. When closing the host computer, terminate all threads and exit the program.

[0150] based on Figure 3 The following example illustrates the initial debugging process of SOME / IP.

[0151] Debugging Background Assumptions: The goal is to debug the request and response mechanism of the UDP-based service `get_speed`. The debugging tool designed in this paper acts as the server providing the `get_speed` service, while the device under test acts as the client making service requests. The project requirements document specifies detailed requirements for both the client and server parameters, such as the simulated MAC address, IP address, UDP port number, ARP response packets, and service parameters provided in the SOME / IP-SD offer message. The debugging process is as follows:

[0152] 1. The computer and the device being debugged are directly connected using a network cable;

[0153] 2. Open the debugging tool on the computer and enter the initial parameters (step S1);

[0154] 3. Select the network port that connects the computer to the device being debugged, and click Open (Step S2);

[0155] 4. The debugging tool starts periodically sending offer messages carrying the get_speed service, and starts listening (steps S3 and S4);

[0156] 5. During the debugging process, if the device under test is normal, it should send an ARP request message as a client.

[0157] 6. The debugging tool, acting as a server, receives ARP request packets, executes step S51, replies with an ARP response (step S53), and returns to step S4;

[0158] 7. During the debugging process, if the device under test is normal, a SOME / IPRequest message should be sent to request the get_speed service after receiving the ARP response;

[0159] 8. The debugging tool, acting as a server, receives the Request message, executes step S62, replies with Responses (step S64), and returns to step S4;

[0160] 9. End debugging (step S7).

[0161] Based on the debugging method provided by the embodiments of the present invention, the first message is periodically sent according to the obtained initial parameters and network port, while the network port is monitored, and the monitored second message is parsed and responded to, thereby enabling SOME / IP preliminary debugging to be performed on the computer when connected to the test board through the network port.

[0162] Compared with the above embodiments of the present invention Figure 1 Corresponding to the debugging method shown, this embodiment of the invention also provides a debugging device, such as... Figure 5 As shown, the device is suitable for the server side, which is equipped with debugging tools. The device includes: an acquisition module 51 and a message sending and listening module 52.

[0163] The acquisition module 51 is used to acquire the initial parameters and the selected network port input by the user.

[0164] The initial parameters include the debugging parameters simulated by the debugging tool and the service parameters provided in the first message. The debugging parameters include the simulated physical address, and the service parameters include the session number for service discovery and the identifier of the Internet Protocol IP. The network port is the network port through which the server connects to the device being debugged.

[0165] The message sending and listening module 52 is used to execute the main message sending process and the message listening process in parallel according to the initial parameters and the network interface.

[0166] The message sending and listening module 52 for sending messages includes:

[0167] The sending unit is used to send the first message to the device under test according to the initial parameters and a preset period. Each time the first message is sent, the session number and the identifier number are incremented by one.

[0168] The message sending and listening module 52 for message monitoring includes:

[0169] The monitoring unit is used to monitor the network port in real time.

[0170] The parsing and feedback unit is used to parse the second message when the network port receives the second message sent by the device under test, and to feed back the response information of the second message to the device under test.

[0171] Optionally, based on the above Figure 5 The message sending and listening module 52 shown includes the parsing and feedback unit, which comprises:

[0172] The parsing subunit is used to parse the second message sent by the device under test when the network interface receives the second message, and obtain the target physical address of the device under test.

[0173] The feedback subunit is used to send the response information of the second message back to the device being debugged, based on the type of the target physical address.

[0174] The target physical address types include multicast or broadcast addresses and analog physical addresses.

[0175] Optionally, based on the above Figure 5 The message sending and listening module 52 shown, specifically the feedback subunit, is used for:

[0176] If the target physical address is the multicast or broadcast address, determine whether the second message is the third message; if so, generate the response information of the third message according to the multicast or broadcast address, and feed the response information of the third message back to the device being debugged, and increment the identifier by one.

[0177] Optionally, based on the above Figure 5 The message sending and listening module 52 shown, the feedback subunit, is further specifically used for:

[0178] If not, determine whether the second message is the same as the first message; if yes, there is no need to reply to the device being debugged with the response information of the second message, and return to the step of executing the real-time monitoring of the network port; if not, directly return to the step of executing the real-time monitoring of the network port.

[0179] Optionally, based on the above Figure 5 The message sending and listening module 52 shown, specifically the feedback subunit, is used for:

[0180] If the target physical address is a simulated physical address, determine whether the second packet is the fourth packet; if so, parse the fourth packet to obtain the subscription service item information; based on the subscription service item information, generate the response information of the fourth packet, and send the response information of the fourth packet back to the device being debugged, incrementing the session number and identifier number by one.

[0181] Optionally, based on the above Figure 5 The message sending and listening module 52 shown, the feedback subunit, is further specifically used for:

[0182] If not, determine whether the second message is the fifth message; if so, parse the fifth message to obtain the fifth message information; based on the fifth message information, generate the response information of the fifth message and send the response information of the fifth message back to the device being debugged, and increment the session number and identifier number by one.

[0183] Optionally, based on the above Figure 5 The debugging apparatus shown, after the feedback subunit is used to feed back the response information to the device being debugged, is also specifically used for:

[0184] Return to the step of performing real-time monitoring of the network interface.

[0185] Optionally, based on the above Figure 5 The debugging device shown, combined with Figure 5 After the monitoring module is used for real-time monitoring of the network interface, it is also used for:

[0186] If the network port does not receive the second message sent by the device being debugged, return to the step of real-time monitoring of the network port.

[0187] It should be noted that the specific principles and execution processes of each module or unit in the debugging device disclosed in the above embodiments of the present invention are the same as those of the debugging method implemented in the above embodiments of the present invention. Please refer to the corresponding parts of the debugging method disclosed in the above embodiments of the present invention, which will not be repeated here.

[0188] Based on the debugging device provided in this embodiment of the invention, the device periodically sends a first message according to the acquired initial parameters and network port, while simultaneously monitoring the network port, parsing the monitored second message and responding accordingly, thereby enabling SOME / IP pre-debugging when the test board is connected to the computer via the network port.

[0189] Corresponding to the debugging method shown in the above embodiments of the present invention, the present invention also provides a debugging system, which includes a server and a client. The server is equipped with debugging tools, and the client is the device being debugged.

[0190] The server-side component obtains the initial parameters and selected network interface from the user input. The initial parameters include debugging parameters simulated by the debugging tool and service parameters provided in the first packet. The debugging parameters include the simulated physical address, and the service parameters include the session number for service discovery and the identifier of the Internet Protocol (IP) IP address. The network interface is the one connected between the server and the device under test. Based on the initial parameters and the network interface, the server executes the main packet sending process and the packet listening process in parallel. The packet sending process includes: sending the first packet to the device under test according to the initial parameters and a preset period, incrementing the session number and identifier number each time the first packet is sent; the packet listening process includes: real-time monitoring of the network interface; when the network interface receives a second packet sent by the device under test, parsing the second packet and feeding back the response information of the second packet to the device under test.

[0191] The client is used to receive the first message sent by the server, send the second message to the server, and receive the response information of the second message sent by the server.

[0192] Based on the debugging system provided in this embodiment of the invention, the system periodically sends a first message according to the acquired initial parameters and network port, while simultaneously monitoring the network port, parsing and responding to the monitored second message, thereby enabling SOME / IP pre-debugging when the test board is connected to the computer via the network port.

[0193] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, for system or system embodiments, since they are basically similar to method embodiments, the description is relatively simple, and relevant parts can be referred to the descriptions in the method embodiments. The systems and system embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. Those skilled in the art can understand and implement this without creative effort.

[0194] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementations should not be considered beyond the scope of this invention.

[0195] The above description of the disclosed embodiments enables those skilled in the art to make or use the invention. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the invention. Therefore, the invention is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A debugging method, characterized in that, Applicable to the server side, the server side is equipped with debugging tools, which are used to perform preliminary testing of SOME / IP on a computer connected to the test board via a network port. The method includes: The system obtains the initial parameters and the selected network port input by the user. The initial parameters include the debugging parameters simulated by the debugging tool and the service parameters provided in the first message. The debugging parameters include the simulated physical address. The service parameters include the session number of service discovery and the identifier of Internet Protocol IP. The network port is the network port through which the server connects to the device being debugged. Based on the initial parameters and the network interface, the main process of sending packets and the process of listening packets are executed in parallel. The main process for sending messages includes: According to the initial parameters, the first message is sent to the device under test according to a preset period. Each time the first message is sent, the session number and the identifier number are incremented by one. The message monitoring process includes: Real-time monitoring of the network port; When the network port receives the second message sent by the device under test, it parses the second message and feeds back the response information of the second message to the device under test.

2. The method according to claim 1, characterized in that, When the network port receives the second message sent by the device under test, parsing the second message and feeding back the response information of the second message to the device under test includes: When the network port receives the second message sent by the device under test, it parses the second message to obtain the target physical address of the device under test; Based on the type of the target physical address, the response information of the second message is fed back to the device under debugging. The type of the target physical address includes multicast or broadcast addresses and simulated physical addresses.

3. The method according to claim 2, characterized in that, The step of feeding back the response information of the second message to the device under debugging according to the type of the target physical address includes: If the target physical address is the multicast or broadcast address, determine whether the second message is a third message; If so, based on the multicast or broadcast address, generate the response information of the third message, and feed back the response information of the third message to the device under debugging, and increment the identifier number by one.

4. The method according to claim 3, characterized in that, Also includes: If not, determine whether the second message is the first message; If so, there is no need to reply to the device under debugging with the response information of the second message, and the process returns to the step of real-time monitoring of the network port; If not, return directly to the step of performing real-time monitoring of the network port.

5. The method according to claim 2, characterized in that, The step of feeding back the response information of the second message to the device under debugging according to the type of the target physical address includes: If the target physical address is the simulated physical address, determine whether the second packet is the fourth packet; If so, parse the fourth message to obtain the subscription service item information; Based on the subscription service item information, the response information of the fourth message is generated and fed back to the device under debugging, and the session number and the identifier number are incremented by one.

6. The method according to claim 5, characterized in that, Also includes: If not, determine whether the second message is the fifth message; If so, parse the fifth message to obtain the fifth message information; Based on the information in the fifth message, a response message for the fifth message is generated and fed back to the device under debugging. The session number and the identifier number are incremented by one.

7. The method according to any one of claims 1 to 6, characterized in that, After feeding back the response information to the device under debugging, the method further includes: Return to the step of performing real-time monitoring of the network interface.

8. The method according to claim 1, characterized in that, Also includes: If the network port does not receive the second message sent by the device under test, return to the step of real-time monitoring of the network port.

9. A debugging device, characterized in that, Applicable to the server side, the server side is equipped with debugging tools, the debugging tools are used to perform preliminary testing of SOME / IP on the computer side via a network port connection to the test board, the device includes: The acquisition module is used to acquire the initial parameters and the selected network port input by the user. The initial parameters include the debugging parameters simulated by the debugging tool and the service parameters provided in the first message. The debugging parameters include the simulated physical address. The service parameters include the session number of service discovery and the identifier of Internet Protocol IP. The network port is the network port through which the server is connected to the device being debugged. The message sending and listening module is used to execute the main message sending process and the message listening process in parallel according to the initial parameters and the network interface. The message sending and listening module includes: The sending unit is configured to send the first message to the device under test according to the initial parameters and a preset period, wherein the session number and the identifier number are incremented by one each time the first message is sent; The message sending and listening module also includes: A monitoring unit is used to monitor the network port in real time; The parsing and feedback unit is used to parse the second message when the network port receives the second message sent by the device under test, and to feed back the response information of the second message to the device under test.

10. A debugging system, characterized in that, The system includes a server and a client. The server is equipped with a debugging tool, which is used to perform preliminary testing of SOME / IP on a computer connected to a test board via a network port. The client is the device being debugged. The server is used to obtain initial parameters and a selected network port input by the user. The initial parameters include debugging parameters simulated by the debugging tool and service parameters provided in the first message. The debugging parameters include a simulated physical address, and the service parameters include a session number for service discovery and an Internet Protocol (IP) identifier. The network port is the network port through which the server connects to the device under test. Based on the initial parameters and the network port, the server executes a main message sending process and a message listening process in parallel. The main message sending process includes: sending the first message to the device under test according to the initial parameters and a preset period, incrementing the session number and identifier number each time the first message is sent; the message listening process includes: monitoring the network port in real time; when the network port receives a second message sent by the device under test, parsing the second message and feeding back the response information of the second message to the device under test. The client is configured to receive the first message sent by the server, send a second message to the server, and receive response information from the server regarding the second message.

Images