Vehicle-mounted network detection method and related device

Abstract

The invention discloses a vehicle-mounted network detection method and a related device, and relates to the technical field of vehicle communication, detection result data of at least two detection objects by an Internet packet explorer is acquired, and the detection objects at least comprise IP addresses. And then carrying out statistics on data of a response data packet in the detection result data to obtain feature data representing a network state. And on this basis, based on the feature data, a final judgment result of whether the network state is abnormal is obtained. Compared with an existing detection mode adopting a single IP address, misjudgment of the network state is not prone to occurring, and the accuracy of network state judgment is improved.

Description

Technical Field

[0001] This application relates to the field of vehicle communication technology, and in particular to a method and related device for detecting vehicle networks. Background Technology

[0002] As vehicles become increasingly intelligent, many functions require internet connectivity. Any network connectivity issues will disrupt these functions and negatively impact the user experience. Therefore, detecting and managing in-vehicle network anomalies is crucial.

[0003] Current network detection solutions employ network diagnostic tools to request hosts or servers on the network at a fixed frequency through a single IP address, using the returned results as the criterion for determining network anomalies. If a host or server malfunctions, even if the network is actually functioning normally, the resulting assessment will still indicate network anomaly, easily leading to misjudgments of the network status. Summary of the Invention

[0004] In view of the above problems, this application provides a method and related apparatus for detecting vehicle network status, so as to reduce network status misjudgment and improve judgment accuracy. The specific solution is as follows:

[0005] The first aspect of this application provides a method for detecting in-vehicle networks, including:

[0006] Obtain detection result data of a first preset number of detection objects by the Internet packet explorer, wherein the detection objects include at least: IP addresses, and the first preset number is not less than 2;

[0007] Statistical analysis is performed on the response data packets in the detection result data to obtain characteristic data representing the network state;

[0008] Based on the aforementioned feature data, it is determined whether the network status is abnormal.

[0009] In one possible implementation, the process of acquiring detection result data of the Internet packet explorer for a first preset number of detection objects includes:

[0010] Within a detection cycle, the process from obtaining the detection result data of the Internet packet explorer for a first preset number of detection objects to the step of judging whether the network status is abnormal is executed N times in sequence. If the network status is normal based on the judgment result obtained in the previous time, the number of objects detected by the Internet packet explorer will remain unchanged in the next time.

[0011] If the network status is abnormal based on the previous judgment result, the number of objects detected by the Internet packet explorer in the next detection cycle will be increased by a first preset increment value, and the final result of the network status in the current detection cycle will be determined based on the last judgment result, where N is an integer not less than 2.

[0012] In one possible implementation, when the detection object also includes a domain name, it further includes:

[0013] During the detection period, the resolution result data for the domain name is obtained;

[0014] The resolution result data is processed based on the domain name judgment strategy to determine whether the domain name server is abnormal;

[0015] If not, the domain name will be added to the next list of targets detected by the Internet packet explorer;

[0016] If so, the number of domains to be checked next time will be increased by the second set increment value.

[0017] In one possible implementation, the feature data includes the number of response packets, and determining whether the network status is abnormal based on the feature data includes:

[0018] Determine whether the ratio of the number of response data packets to the first preset number is not greater than the anomaly determination value; if so, determine that the network status is normal.

[0019] In one possible implementation, the feature data includes: average reception latency and packet loss rate, and the step of determining whether the network status is abnormal based on the feature data includes:

[0020] Based on the correspondence between the average reception delay and the packet loss rate and the network segmentation state judgment conditions, the corresponding network state is determined.

[0021] In one possible implementation, determining the corresponding network state based on the correspondence between the average reception delay and the packet loss rate and the network segmentation state judgment conditions includes:

[0022] If the average reception latency is less than the minimum value of the configured congestion duration interval and the packet loss rate is less than the packet loss rate threshold, then the network is judged to be smooth.

[0023] If the average reception delay is within the congestion duration interval and the packet loss rate is less than the packet loss rate threshold, then the network is judged to be in a state of mild congestion.

[0024] If the average reception delay is greater than the maximum value of the congestion duration interval but less than the network anomaly judgment duration, or if the packet loss rate is greater than the packet loss rate threshold, then the network is judged to be severely congested.

[0025] If the average reception delay is greater than the network anomaly judgment time, then the network status is judged to be abnormal.

[0026] In one possible implementation, when the determination result indicates an abnormal network state, it also includes:

[0027] The registration status of the network card and the creation status of the socket are checked to determine whether there is a network disconnection or an abnormal socket creation.

[0028] In one possible implementation, the vehicular network detection method further includes:

[0029] In response to a request to retrieve detection results, output the judgment result indicating whether the network state is abnormal in the detection period most recently since the request was made.

[0030] A second aspect of this application provides an in-vehicle network detection device, comprising:

[0031] The detection result acquisition module is used to acquire the detection result data of the Internet packet explorer for a first preset number of detection objects, the detection objects including: IP address and / or domain name, the first preset number is not less than 2;

[0032] The feature data acquisition module is used to statistically analyze the response data packets in the detection result data to obtain feature data characterizing the network state; and

[0033] The network status judgment module is used to determine whether the network status is abnormal based on the feature data.

[0034] A third aspect of this application provides an electronic device, comprising at least one processor and a memory connected to the processor, wherein:

[0035] The memory is used to store computer programs;

[0036] The processor is used to execute the computer program so that the electronic device can implement the vehicle network detection method of the first aspect or any implementation thereof.

[0037] A fourth aspect of this application provides a vehicle that includes the electronic equipment described in the third aspect above.

[0038] The fifth aspect of this application provides a computer program product including computer-readable instructions that, when executed on an electronic device, cause the electronic device to implement the vehicle network detection method of the first aspect or any implementation thereof.

[0039] The sixth aspect of this application provides a computer-readable storage medium carrying one or more computer programs that, when executed by an electronic device, enable the electronic device to implement the vehicle network detection method described in the first aspect or any implementation thereof.

[0040] By employing the above technical solution, the vehicle network detection method provided in this application acquires detection result data from an Internet packet explorer for at least two detection objects, wherein the detection objects may include at least an IP address. Then, it statistically analyzes the response data packets representing network status in the detection result data to obtain characteristic data representing the network status. Based on this characteristic data, a final judgment result on whether the network status is abnormal is obtained. Compared to existing methods that use a single IP address for detection, this method is less prone to misjudgment of network status, thus improving the accuracy of network status judgment. Attached Figure Description

[0041] The above and other features, advantages, and aspects of the embodiments of this disclosure will become more apparent from the accompanying drawings and the following detailed description. Throughout the drawings, the same or similar reference numerals denote the same or similar elements. It should be understood that the drawings are schematic, and the originals and elements are not necessarily drawn to scale.

[0042] Figure 1 A structural diagram of an in-vehicle network detection system provided in this application;

[0043] Figure 2 A structural diagram of the terminal provided in this application;

[0044] Figure 3 The structural diagram of the server provided in this application;

[0045] Figure 4 A flowchart of an in-vehicle network detection method provided in this application;

[0046] Figure 5 A flowchart illustrating the specific application of an in-vehicle network detection method provided in this application;

[0047] Figure 6 A structural diagram of an in-vehicle network detection device provided in this application;

[0048] Figure 7 A structural diagram of the electronic device provided in this application. Detailed Implementation

[0049] The embodiments of this application are described below with reference to the accompanying drawings. The terminology used in the implementation section of this application is for explaining specific embodiments only and is not intended to limit the scope of this application.

[0050] The embodiments of this application will now be described with reference to the accompanying drawings. Those skilled in the art will recognize that, with technological advancements and the emergence of new scenarios, the technical solutions provided in the embodiments of this application are equally applicable to similar technical problems.

[0051] The terms "first," "second," etc., used 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 terms are interchangeable where appropriate; this is merely a way of distinguishing objects with the same attributes in the embodiments of this application. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion, so that a process, method, system, product, or apparatus that comprises a series of elements is not necessarily limited to those elements, but may include other elements not explicitly listed or inherent to those processes, methods, products, or apparatuses.

[0052] See Figure 1 , Figure 1 A schematic diagram of a system architecture is shown. The system may include a terminal 100 and a server 200. The server 200 may include one or more servers (…). Figure 1 (The example includes a server), and the server 200 can provide the method provided in the embodiments of this application to one or more terminals.

[0053] The terminal 100 may be equipped with an in-vehicle network detection application. The application and webpage can provide an interface. The terminal 100 can receive relevant parameters input by the user on the parameter configuration interface and send the parameters to the server 200. The server 200 can obtain the processing result based on the received parameters and return the processing result to the terminal 100.

[0054] It should be understood that in some optional implementations, the terminal 100 can also complete the action of obtaining the processing result based on the received parameters on its own, without the need for the server to cooperate. This application embodiment is not limited to this.

[0055] The following description Figure 1 The product form of the mid-terminal 100;

[0056] The terminal 100 in this application embodiment can be an ECU (Electronic Control Unit), VCU (Vehicle Control Unit), MCU (Micro Controller Unit), HCU (Hybrid Control Unit), mobile phone, tablet computer, wearable device, in-vehicle device, augmented reality (AR) / virtual reality (VR) device, laptop computer, ultra-mobile personal computer (UMPC), netbook, personal digital assistant (PDA), etc., and this application embodiment does not impose any restrictions on it.

[0057] Figure 2 A schematic diagram of an optional hardware structure for terminal 100 is shown.

[0058] refer to Figure 2 As shown, the terminal 100 may include a radio frequency unit 110, a memory 120, an input unit 130, a display unit 140, a camera 150 (optional), an audio circuit 160 (optional), a speaker 161 (optional), a microphone 162 (optional), a headphone jack 163 (optional), a processor 170, an external interface 180, a power supply 190, and other components. Those skilled in the art will understand that... Figure 2 These are merely examples of terminals or multi-functional devices and do not constitute a limitation on terminals or multi-functional devices. They may include more or fewer components than shown in the illustration, or combine certain components, or use different components.

[0059] The input unit 130 can be used to receive input numerical or character information, and to generate key signal inputs related to user settings and function control of the portable multi-functional device. Specifically, the input unit 130 may include a touchscreen 131 (optional) and / or other input devices 132. The touchscreen 131 can collect touch operations performed by the user on or near it (such as operations performed by the user using fingers, knuckles, styluses, or any suitable object on or near the touchscreen), and drive the corresponding connection devices according to a pre-set program. The touchscreen can detect the user's touch actions, convert the touch actions into touch signals and send them to the processor 170, and can receive and execute commands sent by the processor 170; the touch signal includes at least touch point coordinate information. The touchscreen 131 can provide an input interface and an output interface between the terminal 100 and the user. In addition, various types of touchscreens, such as resistive, capacitive, infrared, and surface acoustic wave, can be used to implement the touchscreen. Besides the touchscreen 131, the input unit 130 may also include other input devices. Specifically, other input devices 132 may include, but are not limited to, one or more of the following: physical keyboard, function keys (such as volume control buttons, power buttons, etc.), trackball, mouse, joystick, etc.

[0060] Among them, the input device 132 can receive input data, etc.

[0061] The display unit 140 can be used to display information input by the user or information provided to the user, various menus of the terminal 100, interactive interfaces, file display, and / or playback of any multimedia file. In this embodiment, the display unit 140 can be used to display the parameter configuration interface and processing results of vehicle network detection.

[0062] The memory 120 can be used to store instructions and data. The memory 120 may primarily include an instruction storage area and a data storage area. The data storage area can store various types of data, such as multimedia files and text. The instruction storage area can store software units such as operating systems, applications, and instructions required for at least one function, or subsets or extended sets thereof. It may also include non-volatile random access memory. It provides the processor 170 with hardware, software, and data resources for managing the computing device, supporting control software and applications. It is also used for storing multimedia files, as well as storing running programs and applications.

[0063] The processor 170 is the control center of the terminal 100. It connects various parts of the terminal 100 via various interfaces and lines. By running or executing instructions stored in the memory 120 and calling data stored in the memory 120, it performs various functions and processes data of the terminal 100, thereby controlling the terminal device as a whole. Optionally, the processor 170 may include one or more processing units; preferably, the processor 170 may integrate an application processor and a modem processor, wherein the application processor mainly handles the operating system, user interface, and applications, and the modem processor mainly handles wireless communication. It is understood that the modem processor may not be integrated into the processor 170. In some embodiments, the processor and memory can be implemented on a single chip; in some embodiments, they can also be implemented separately on independent chips. The processor 170 can also be used to generate corresponding operation control signals, send them to the corresponding components of the computing processing device, read and process data in the software, especially read and process data and programs in the memory 120, so that the various functional modules therein perform corresponding functions, thereby controlling the corresponding components to act according to the instructions.

[0064] The memory 120 can be used to store software code related to the vehicle network detection method, and the processor 170 can execute the steps of the vehicle network detection method, and can also schedule other units (such as the above-mentioned input unit 130 and display unit 140) to achieve the corresponding functions.

[0065] The radio frequency unit 110 (optional) can be used for receiving and transmitting signals during information transmission or calls. For example, it can receive downlink information from the base station and process it for the processor 170; additionally, it can transmit uplink data to the base station. Typically, the RF circuit includes, but is not limited to, an antenna, at least one amplifier, a transceiver, a coupler, a low-noise amplifier (LNA), a duplexer, etc. Furthermore, the radio frequency unit 110 can also communicate wirelessly with network devices and other devices. This wireless communication can use any communication standard or protocol, including but not limited to Global System for Mobile communication (GSM), General Packet Radio Service (GPRS), Code Division Multiple Access (CDMA), Wideband Code Division Multiple Access (WCDMA), Long Term Evolution (LTE), email, Short Messaging Service (SMS), etc.

[0066] In this embodiment of the application, the radio frequency unit 110 can send the Internet packet explorer detection result data to the server 200 and receive the result data on whether the network status is abnormal sent by the server 200.

[0067] It should be understood that the radio frequency unit 110 is optional and can be replaced with other communication interfaces, such as a network port.

[0068] The terminal 100 also includes a power supply 190 (such as a battery) that supplies power to various components. Preferably, the power supply can be logically connected to the processor 170 through a power management system, thereby enabling functions such as charging, discharging, and power consumption management through the power management system.

[0069] Terminal 100 also includes an external interface 180, which can be a standard Micro USB interface or a multi-pin connector, which can be used to connect terminal 100 to other devices for communication or to connect a charger to charge terminal 100.

[0070] Although not shown, terminal 100 may also include a flash, a wireless fidelity (WiFi) module, a Bluetooth module, sensors with various functions, etc., which will not be described in detail here. Some or all of the methods described below can be applied to, for example... Figure 2 In the terminal 100 shown.

[0071] The following description Figure 1 The product form of the mid-range server 200;

[0072] Figure 3 A structural diagram of a server 200 is provided, as follows: Figure 3 As shown, server 200 includes bus 201, processor 202, communication interface 203, and memory 204. Processor 202, memory 204, and communication interface 203 communicate with each other via bus 201.

[0073] Bus 201 can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of representation, Figure 3 The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.

[0074] The processor 202 can be any one or more of the following processors: central processing unit (CPU), graphics processing unit (GPU), microprocessor (MP), or digital signal processor (DSP).

[0075] Memory 204 may include volatile memory, such as random access memory (RAM). Memory 204 may also include non-volatile memory, such as read-only memory (ROM), flash memory, hard disk drive (HDD), or solid state drive (SSD).

[0076] The memory 204 can be used to store software code related to the vehicle network detection method, and the processor 202 can execute the steps of the chip's vehicle network detection method, and can also schedule other units to achieve corresponding functions.

[0077] It should be understood that the aforementioned terminal 100 and server 200 can be centralized or distributed devices. The processors (e.g., processor 170 and processor 202) in the aforementioned terminal 100 and server 200 can be hardware circuits (such as application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), general-purpose processors, digital signal processors (DSPs), microprocessors or microcontrollers, etc.) or combinations of these hardware circuits. For example, the processor can be a hardware system with instruction execution capabilities, such as a CPU or DSP, or a hardware system without instruction execution capabilities, such as an ASIC or FPGA, or a combination of the aforementioned hardware systems without instruction execution capabilities and hardware systems with instruction execution capabilities.

[0078] Currently, existing network detection solutions in vehicles typically ping a specific address at a fixed frequency, such as pinging the IP address 106.13.249.128 once per minute. Ping (Packet Internet Groper) is a computer network management application used to verify the reachability of a host on the Internet. It verifies the connection to the host or server by sending data packets to the IP address and listening for response packets.

[0079] If the server corresponding to 106.13.249.128 malfunctions, all Ping operations to 106.13.249.128 will fail, even though the network connection between the vehicle and the server is actually working. The network status determination result obtained from the detection results is that the network status is abnormal, thus leading to a false judgment of network status abnormality.

[0080] To address the aforementioned problems, this application provides a method for detecting in-vehicle networks. The method described below, with reference to the accompanying drawings, will be described in detail.

[0081] Reference Figure 4 , Figure 4 This is a flowchart illustrating a vehicle network detection method provided in an embodiment of this application, as shown below. Figure 4 As shown in the embodiment of this application, a vehicle network detection method may include steps 401 to 403, which are described in detail below.

[0082] 401. Obtain the detection result data of the Internet packet explorer for a first preset number of detection objects, wherein the detection objects include at least: IP addresses, and the first preset number is not less than 2.

[0083] Specifically, during each vehicle network test, at least two IP addresses can be used as targets for the Internet packet explorer. The Internet packet explorer is then activated to test each IP address. During the test of each IP address, test packets can be sent at a set frequency; for example, after sending four test packets within 5 seconds, the system waits to receive response packets for each test packet.

[0084] It is understood that those skilled in the art can adjust and select the number and frequency of data packets sent by the Internet Packet Explorer as needed, and no restrictions are imposed here.

[0085] 402. Statistical analysis is performed on the response data packets in the detection results to obtain characteristic data representing the network status.

[0086] Specifically, the data in the response data packet can include the number of response data packets and the values ​​of the response parameters contained in the response data packet, such as the reception delay and the number of lost packets. After statistical analysis of all response data packets, three characteristic data can be obtained: the number of response data packets, the average reception delay, and the packet loss rate.

[0087] 403. Determine whether the network status is abnormal based on feature data.

[0088] Specifically, based on the aforementioned characteristic data, the corresponding characteristic data can be processed according to a pre-set network status judgment strategy to determine whether the network status is abnormal. For example, if at least one response data packet is received within 5 seconds of waiting for a response data packet, the network status can be determined to be normal. Conversely, if no response data packet is received, the network status can be determined to be abnormal.

[0089] For example, to obtain a more detailed network status, the corresponding network status can be determined based on the correspondence between average reception delay and packet loss rate and the network segmentation status judgment conditions.

[0090] It should be noted that those skilled in the art can make adaptive adjustments to the network state determination strategy and the corresponding feature data as needed, and no restrictions are imposed here.

[0091] As can be seen from the above, the vehicle network detection method provided in this application does not rely on the Ping detection result of a single IP address, but instead performs Ping detection on multiple IP addresses and combines the returned detection result data to determine the network status. This can effectively reduce the occurrence of misjudgments of network status and improve the accuracy and reliability of vehicle network status determination.

[0092] In one possible implementation, considering that network state anomalies caused by network fluctuations may last only a few seconds, in order to obtain the corresponding network state diagnosis results in a shorter time, step 403 above, which processes the feature data based on the network state judgment strategy to determine whether the network state is abnormal, may specifically include the following process:

[0093] Determine if the ratio of the number of response data packets to the first preset number is not greater than the anomaly detection value; if so, determine that the network status is normal.

[0094] Specifically, when network anomalies occur, after initiating a Ping test, the number of received response packets will be very small or nonexistent within a set reception time, such as 5 seconds. Considering this abnormal network condition, the proportion of returned response packets can be used to more quickly determine if a network anomaly exists. For example, if 8 test packets are sent to 2 IP addresses, and only 1 response packet is received within the 5-second waiting period, the ratio of the number of response packets to the first preset number is 0.5, while the anomaly detection value is 1. Therefore, the network condition can be determined to be abnormal.

[0095] It is understood that those skilled in the art can adjust and select the above-mentioned anomaly determination values ​​as needed, which will not be elaborated here.

[0096] In one possible implementation, to obtain a more detailed and accurate network state so that subsequent programs can adopt more suitable solutions to adjust the network state, the corresponding network state is determined based on the correspondence between average reception latency and packet loss rate and network segmentation state judgment conditions. This can specifically include the following process:

[0097] If the average reception latency is less than the minimum value of the configured congestion duration interval and the packet loss rate is less than the packet loss rate threshold, then the network is considered to be in good condition.

[0098] If the average reception delay is within the congestion duration range and the packet loss rate is less than the packet loss rate threshold, then the network is judged to be slightly congested.

[0099] If the average reception delay is greater than the maximum value of the congestion duration interval but less than the network anomaly judgment duration, or if the packet loss rate is greater than the packet loss rate threshold, then the network is judged to be severely congested.

[0100] If the average reception delay is greater than the network anomaly judgment duration, it is judged that the network state is abnormal.

[0101] Specifically, judgment conditions for the average reception delay and packet loss rate can be set for each network state. Based on this, the statistically obtained average reception delay and packet loss rate can be correspondingly matched to obtain the corresponding network state. For example:

[0102] The congestion duration range is: JamTime[2] = {100, 500}, with the unit being milliseconds.

[0103] The network anomaly judgment duration is: DisTime = 5000, with the unit being milliseconds. The judgment process for each sub-network state can be:

[0104] Network smooth: 0 < T < JamTime[0] and dropRate < 20%.

[0105] Network slightly congested: JamTime[0] < T < JamTime[1] and dropRate < 20%.

[0106] Network severely congested: JamTime[1] < T < DisTime or drop Rate > 20%.

[0107] Network state abnormal: DisTime < T.

[0108] Where T is the average reception delay, dropRate is the packet loss rate, 20% is the packet loss rate threshold, JamTime[0] represents 100 milliseconds, and JamTime[1] represents 500 milliseconds. Among them, from network smooth to network severely congested can be classified as normal network states.

[0109] It can be understood that those skilled in the art can adjust the judgment conditions or ranges of each network state as needed, and no limitation is made here.

[0110] In addition, when the judgment result is that the network state is abnormal, in order to further assist in improving the response speed of subsequent anomaly handling programs and reducing the processing duration, the following processing process can also be included:

[0111] Detect the registration state of the network card and the creation state of the socket to determine whether there is network disconnection and abnormal socket creation.

[0112] Specifically, the system checks whether the network card has been switched or restarted to determine if a network disconnection is causing the Ping test to fail, resulting in a network status error. It also excludes cases where an abnormal socket creation could prevent the Ping test from being executed. A socket is a convention or method for communication between computers, providing an interface for communication over a network. Using sockets, connections can be established between different computers to transmit and exchange data; if a socket is not established, the Ping test will fail to execute.

[0113] In one possible implementation, to avoid misjudging network status anomalies when multiple servers simultaneously malfunction and the network status judgment in steps 401 to 403 is executed once, the reliability and accuracy of the network status judgment are further improved. Step 401, the process of obtaining the detection result data of the Internet packet explorer for a first preset number of detection objects, can specifically include the following processing steps:

[0114] Within a detection cycle, the processing steps 401 to 403 above are executed N times in sequence. If the network status is normal based on the judgment result obtained in the previous time, the number of objects detected by the Internet packet explorer remains unchanged in the next time.

[0115] If the network status is abnormal based on the previous judgment result, the number of objects detected by the Internet Packet Explorer in the next detection cycle will be increased by a first preset increment value, and the final result of the network status in the current detection cycle will be determined based on the last judgment result, where N is an integer not less than 2.

[0116] Specifically, a detection cycle can be divided into multiple sub-cycles, and the processing steps 401 to 403 described above are executed within each sub-cycle. When the network status judgment result indicates an abnormal network status, the number of IP addresses in the Internet packet explorer is increased by the first preset increment value, such as increasing from 2 to 3, so that the Internet packet explorer will detect 3 IP addresses. This eliminates the false judgment of an abnormal network status caused by the simultaneous abnormality of servers corresponding to two IPs. When the network status judgment result indicates a normal network status, the current number of IP addresses can be maintained for detection to reduce traffic consumption. To improve the continuous and stable network detection rate under normal or weak network conditions, the acquisition time of detection result data (which can also be understood as the detection cycle) is generally not greater than a preset waiting time threshold, for example, the acquisition time is generally set to no more than 30 seconds, thereby ensuring a detection frequency of at least twice per minute under normal or weak network conditions.

[0117] For example, if the acquisition time of the detection result, i.e., the detection period, is 30 seconds, it is divided into 3 sub-periods, each lasting 10 seconds. Steps 101 to 103 are executed every 10 seconds, adjusting the number of IP addresses in the Internet packet explorer based on the network status assessment.

[0118] In one possible implementation, besides using IP addresses as the detection target of the Internet packet explorer, domain names can also be used. However, when using a domain name for Ping detection, the specific process of the Ping operation is to obtain the IP address corresponding to the domain name from the domain name server, and then send the detection data packet according to the IP address. If the domain name server is abnormal during this process, resulting in the failure to obtain the corresponding IP address, the Ping detection will receive no response data packet, even though the actual network is normal, leading to a misjudgment of abnormal network status.

[0119] To reduce the occurrence of the aforementioned misjudgments and further improve the accuracy of network status judgment, based on the specific implementation process of step 401 above, which involves obtaining the detection result data of the Internet packet explorer for the first preset number of detection objects, when the detection objects also include domain names, the vehicle network detection method may further include the following processing steps:

[0120] Step 1: Obtain the domain name resolution results data within the detection period.

[0121] Step 2: Process the resolution result data based on the domain name judgment strategy to determine whether the domain name server is abnormal.

[0122] Step 3: If not, add the domain name to the next Internet Packet Explorer detection list.

[0123] If so, the number of domains to be checked next time will be increased by the second set increment value.

[0124] Specifically, within each sub-cycle, the domain name resolution results data of the domain name are retrieved simultaneously by the domain name resolution tool. Based on the domain name judgment strategy and the resolution results data, if it is determined that the domain name server is not abnormal, the current number of domain names are added to the detection objects of the Internet Packet Explorer in the next sub-cycle, so that the domain names can be pinged simultaneously in the next sub-cycle.

[0125] If a domain name server is found to be abnormal, a second preset increment value, such as 1, can be added to the current number of domain names. This will allow the domain name resolution tool to resolve the domain names according to the added domain names, thereby determining whether the domain name server is abnormal.

[0126] One domain name resolution strategy is to determine if the domain name server is malfunctioning by counting the number of IP addresses corresponding to the domain name. For example, if even one domain name resolves successfully, the domain name server is considered to be functioning normally. Conversely, if no domain name resolves successfully, the domain name server is considered to be malfunctioning.

[0127] As a specific application of the above embodiments, refer to Figure 5 As shown, after receiving the Ping start test command, the Ping test interval is determined according to the set parameters, i.e., how many seconds each test cycle is entered (30 seconds), and then the normal test process is performed on each network card:

[0128] Simultaneously, IP detection and domain name detection are enabled. In the first sub-cycle (0-10 seconds), two IP addresses are pinged, and four detection data packets are sent to each IP address within 5 seconds. At the same time, the domain name detection tool resolves the two domain names.

[0129] If the detection result for the two IP addresses is successful, indicating that the network status is normal, then the two IP addresses will continue to be used for detection in the second sub-cycle (10-20 seconds). If the detection result is successful, then the two IP addresses will continue to be used for detection in the third sub-cycle (20-30 seconds).

[0130] If the detection result in the second detection sub-cycle is a failure, indicating an abnormal network status, then the third sub-cycle will use three IP addresses for detection, and the final detection result will be obtained.

[0131] Simultaneously, both domain names are resolved within the first sub-cycle. If the domain name resolution is successful, the domain name server is considered to be functioning normally, and the two domain names can be pinged within the second sub-cycle. The domain name resolution tool used here is DNS (Domain Name System).

[0132] If domain name resolution fails within the first sub-cycle (i.e., no IP address corresponding to the domain name is received within 10 seconds), the result is determined to be an abnormal domain name server. Then, the domain name server status based on the three domain names is determined in the second sub-cycle.

[0133] If the detection of two domains passes in the second sub-cycle, the network status is judged to be normal, and the detection of three domains continues in the third sub-cycle.

[0134] If the resolution of the three domain names is successful within the second sub-cycle, indicating that the domain name server is functioning normally, then the three domain names can be pinged in the third sub-cycle.

[0135] Finally, the results of whether the network status of each network card is abnormal are summarized, and the results obtained in the last sub-cycle are used as the basis for collection. When a network card switches between primary and secondary cards, a "network normal" flag 2 is reported, indicating that the final detection result is invalid and not used as a reference result. Figure 5 shown

[0136] RCS detection, when the final output indicates an abnormal network condition, responds to a user's detection result request by extracting the call interval from the request. Then, based on the current time and the call interval, it determines the call time and, upon arrival, outputs the judgment result indicating whether the network condition is abnormal for the most recent detection period. Figure 5 As shown, after the primary and secondary cards are switched, the network identifiers of the six network cards reported to the RCS detection are all 2, that is, UP to RCS:222222.

[0137] Specifically, the interface function is `send_timer_to_ping(timerid_t)`, where `timerid_t` is the obtained call interval. After obtaining this call interval, the system proactively reports the network status anomaly judgment result for the most recent detection period after the `timerid_t` duration. Furthermore, it can combine this with the `sleep(timerid_t-20)` function to perform another network status anomaly judgment process starting from the second sub-period.

[0138] The above describes a vehicle network detection method provided by the embodiments of this application. The following describes the apparatus for performing the above vehicle network detection method.

[0139] Please see Figure 6 , Figure 6 This is a schematic diagram of the structure of an in-vehicle network detection device provided in an embodiment of this application. Figure 6 As shown, the vehicle network detection device 600 includes:

[0140] The detection result acquisition module 601 is used to acquire the detection result data of the Internet packet explorer for a first preset number of detection objects, the detection objects include: IP address and / or domain name, and the first preset number is not less than 2;

[0141] The feature data acquisition module 602 is used to statistically analyze the response data packets in the detection result data to obtain feature data characterizing the network state; and

[0142] The network status judgment module 603 is used to determine whether the network status is abnormal based on feature data.

[0143] In one possible implementation, the process by which the detection result acquisition module 601 acquires the detection result data of the Internet packet explorer for a first preset number of detection objects includes:

[0144] Within a detection cycle, the process of obtaining the detection result data of the Internet packet explorer for the first preset number of detection objects, and the process of judging whether the network status is abnormal will be executed N times in sequence. If the judgment result obtained in the previous time is that the network status is normal, the number of objects detected by the Internet packet explorer will remain unchanged in the next time.

[0145] If the network status is abnormal based on the previous judgment result, the number of objects detected by the Internet Packet Explorer in the next detection cycle will be increased by a first preset increment value, and the final result of the network status in the current detection cycle will be determined based on the last judgment result, where N is an integer not less than 2.

[0146] In one possible implementation, when the detection object also includes a domain name, a resolution result acquisition module is also included, used for:

[0147] During the detection period, the resolution result data for the domain name is obtained;

[0148] The resolution result data is processed based on the domain name judgment strategy to determine whether the domain name server is abnormal;

[0149] If not, the domain name will be added to the next list of targets detected by the Internet packet explorer;

[0150] If so, the number of domains to be checked next time will be increased by the second set increment value.

[0151] In one possible implementation, the acquisition time of the detection result data in the detection result acquisition module 601 is not greater than a preset waiting time threshold.

[0152] In one possible implementation, the feature data includes the number of response packets. The network status determination module 603 determines whether the network status is abnormal based on the feature data, including:

[0153] Determine whether the ratio of the number of response data packets to the first preset number is not greater than the anomaly determination value; if so, determine that the network status is normal.

[0154] In one possible implementation, the feature data includes: average reception latency and packet loss rate. The network status judgment module 603 processes the feature data based on a network status judgment strategy to determine whether the network status is abnormal, including:

[0155] Based on the correspondence between average reception delay and packet loss rate and the network segmentation status judgment conditions, the corresponding network status is determined.

[0156] In one possible implementation, the network state determination module 603 determines the corresponding network state based on the correspondence between average reception delay and packet loss rate and network segmentation state determination conditions, including:

[0157] If the average reception latency is less than the minimum value of the configured congestion duration interval and the packet loss rate is less than the packet loss rate threshold, then the network is considered to be smooth.

[0158] If the average reception delay is within the congestion duration interval and the packet loss rate is less than the packet loss rate threshold, then the network is judged to be slightly congested.

[0159] If the average reception delay is greater than the maximum value of the congestion duration interval but less than the network anomaly judgment duration, or if the packet loss rate is greater than the packet loss rate threshold, then the network is judged to be severely congested.

[0160] If the average reception delay is greater than the network anomaly detection time, then the network status is judged to be abnormal.

[0161] In one possible implementation, when the judgment result is an abnormal network status, it also includes: an abnormal result processing module, which is used to detect the registration status of the network card and the creation status of the socket to determine whether there is a network disconnection or an abnormal socket creation.

[0162] In one possible implementation, it also includes: a judgment result calling module, used for:

[0163] In response to a request to retrieve detection results, output the judgment result indicating whether the network state is abnormal in the detection period most recently since the request was made.

[0164] This application also provides an electronic device in its embodiments. (See reference...) Figure 7 The diagram illustrates a structural schematic suitable for implementing the electronic device in the embodiments of this application. The electronic device in the embodiments of this application may include, but is not limited to, fixed terminals such as mobile phones, laptops, PDAs (personal digital assistants), PADs (tablet computers), desktop computers, etc. Figure 7 The electronic device shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments of this application.

[0165] like Figure 7As shown, the electronic device may include a processing unit (e.g., a central processing unit, a graphics processing unit, etc.) 701, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 702 or a program loaded from a storage device 708 into a random access memory (RAM) 703. When the electronic device is powered on, the RAM 703 also stores various programs and data required for the operation of the electronic device. The processing unit 701, ROM 702, and RAM 703 are interconnected via a bus 704. An input / output (I / O) interface 705 is also connected to the bus 704.

[0166] Typically, the following devices can be connected to I / O interface 705: input devices 706 including, for example, touchscreens, touchpads, keyboards, mice, cameras, microphones, accelerometers, gyroscopes, etc.; output devices 707 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 708 including, for example, memory cards, hard drives, etc.; and communication devices 709. Communication device 709 allows electronic devices to communicate wirelessly or wiredly with other devices to exchange data. Although Figure 7 Electronic devices with various devices are shown, but it should be understood that it is not required to implement or have all of the devices shown. More or fewer devices may be implemented or have alternatively.

[0167] This application also provides a vehicle that includes the electronic equipment described in the above embodiments.

[0168] This application also provides a computer program product, including computer-readable instructions, which, when executed on an electronic device, cause the electronic device to implement any of the vehicle network detection methods provided in this application.

[0169] This application also provides a computer-readable storage medium carrying one or more computer programs. When the one or more computer programs are executed by an electronic device, the electronic device can implement any of the vehicle network detection methods provided in this application.

[0170] It should also be noted that the device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate, and 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. In addition, in the device embodiment drawings provided in this application, the connection relationship between modules indicates that they have a communication connection, which can be implemented as one or more communication buses or signal lines.

[0171] Through the above description of the embodiments, those skilled in the art can clearly understand that this application can be implemented by means of software plus necessary general-purpose hardware, or it can be implemented by special-purpose hardware including application-specific integrated circuits, special-purpose CPUs, special-purpose memory, special-purpose components, etc. Generally, any function performed by a computer program can be easily implemented by corresponding hardware, and the specific hardware structure used to implement the same function can also be diverse, such as analog circuits, digital circuits, or special-purpose circuits. However, for this application, software program implementation is more often the preferred implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a readable storage medium, such as a computer floppy disk, USB flash drive, mobile hard disk, ROM, RAM, magnetic disk, or optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, training equipment, or network device, etc.) to execute the methods described in the various embodiments of this application.

[0172] In the above embodiments, the implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented, in whole or in part, in the form of a computer program product.

[0173] The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions may be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions may be transmitted from one website, computer, training device, or data center to another website, computer, training device, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium may be any available medium that a computer can store or a data storage device such as a training device or data center that integrates one or more available media. The available media may be magnetic media (e.g., floppy disks, hard disks, magnetic tapes), optical media (e.g., DVDs), or semiconductor media (e.g., solid-state drives (SSDs)).

Claims

1. A method for detecting vehicle-mounted networks, characterized in that, include: Obtain detection result data of a first preset number of detection objects by the Internet packet explorer, wherein the detection objects include at least: IP addresses, and the first preset number is not less than 2; Statistical analysis is performed on the response data packets in the detection result data to obtain characteristic data representing the network state; Based on the aforementioned feature data, it is determined whether the network status is abnormal.

2. The vehicle network detection method according to claim 1, characterized in that, The process of acquiring the detection result data of the Internet packet explorer for a first preset number of detection objects includes: Within a detection cycle, the process from obtaining the detection result data of the Internet packet explorer for a first preset number of detection objects to the step of judging whether the network status is abnormal is executed N times in sequence. If the network status is normal based on the judgment result obtained in the previous time, the number of objects detected by the Internet packet explorer will remain unchanged in the next time. If the network status is abnormal based on the previous judgment result, the number of objects detected by the Internet packet explorer in the next detection cycle will be increased by a first preset increment value, and the final result of the network status in the current detection cycle will be determined based on the last judgment result, where N is an integer not less than 2.

3. The vehicle network detection method according to claim 2, characterized in that, When the detection object also includes a domain name, it also includes: During the detection period, the resolution result data for the domain name is obtained; The resolution result data is processed based on the domain name judgment strategy to determine whether the domain name server is abnormal; If not, the domain name will be added to the next list of targets detected by the Internet packet explorer; If so, the number of domains to be checked next time will be increased by the second set increment value.

4. The vehicle network detection method according to claim 1, characterized in that, The feature data includes the number of response packets. The step of determining whether the network status is abnormal based on the feature data includes: Determine whether the ratio of the number of response data packets to the first preset number is not greater than the anomaly determination value; if so, determine that the network status is normal.

5. The vehicle network detection method according to claim 1, characterized in that, The characteristic data includes: average reception latency and packet loss rate. The step of determining whether the network status is abnormal based on the characteristic data includes: Based on the correspondence between the average reception delay and the packet loss rate and the network segmentation state judgment conditions, the corresponding network state is determined.

6. The vehicle network detection method according to claim 5, characterized in that, The process of determining the corresponding network state based on the correspondence between the average reception delay and the packet loss rate and the network segmentation state judgment conditions includes: If the average reception latency is less than the minimum value of the configured congestion duration interval and the packet loss rate is less than the packet loss rate threshold, then the network is judged to be smooth. If the average reception delay is within the congestion duration interval and the packet loss rate is less than the packet loss rate threshold, then the network is judged to be in a state of mild congestion. If the average reception delay is greater than the maximum value of the congestion duration interval but less than the network anomaly judgment duration, or if the packet loss rate is greater than the packet loss rate threshold, then the network is judged to be severely congested. If the average reception delay is greater than the network anomaly judgment time, then the network status is judged to be abnormal.

7. The vehicle network detection method according to claim 1, characterized in that, When the judgment result indicates that the network status is abnormal, it also includes: The registration status of the network card and the creation status of the socket are checked to determine whether there is a network disconnection or an abnormal socket creation.

8. The vehicle network detection method according to claim 1, characterized in that, Also includes: In response to a request to retrieve detection results, output the judgment result indicating whether the network state is abnormal in the detection period most recently since the request was made.

9. A vehicle-mounted network detection device, characterized in that, include: The detection result acquisition module is used to acquire the detection result data of the Internet packet explorer for a first preset number of detection objects, the detection objects including: IP address and / or domain name, the first preset number is not less than 2; The feature data acquisition module is used to statistically analyze the response data packets in the detection result data to obtain feature data characterizing the network state; and The network status judgment module is used to determine whether the network status is abnormal based on the feature data.

10. An electronic device, characterized in that, It includes at least one processor and a memory connected to the processor, wherein: The memory is used to store computer programs; The processor is used to execute the computer program to enable the electronic device to implement the vehicle network detection method as described in any one of claims 1 to 8.

11. A vehicle, characterized in that, Including the electronic device as described in claim 10.

12. A computer program product, characterized in that, It includes computer-readable instructions that, when executed on an electronic device, cause the electronic device to implement the vehicle network detection method as described in any one of claims 1 to 8.

13. A computer-readable storage medium, characterized in that, The storage medium carries one or more computer programs that, when executed by an electronic device, enable the electronic device to implement the vehicle network detection method as described in any one of claims 1 to 8.

Images