Vehicle machine system fault positioning method and device and vehicle

Abstract

The application discloses a car machine system fault positioning method and device and a vehicle, and is applied to the technical field of real vehicle testing. The method comprises the following steps: performing real vehicle testing on a car machine system of a vehicle to obtain an execution stack of each scheduling link of the car machine system. Different scheduling links are links connecting different architecture layers of the car machine system, and the execution stack of the scheduling link is used for storing a plurality of function functions and a plurality of variable values of the scheduling link during the real vehicle testing. Abnormal detection is performed on the car machine system to obtain an abnormal detection result, wherein the abnormal detection result is used for representing whether the car machine system is abnormal during the real vehicle testing. If the abnormal detection result is that the car machine system is abnormal during the real vehicle testing, the function function existing abnormality and the variable value existing abnormality in the car machine system are determined according to the execution stack of each scheduling link. The application can improve the fault positioning accuracy of the car machine system in the real vehicle testing stage.

Description

Technical Field

[0001] This application relates to the field of real vehicle testing technology, and in particular to methods, devices and vehicles for locating faults in vehicle infotainment systems. Background Technology

[0002] A vehicle infotainment system (VIS) refers to an electronic system installed in a vehicle to provide information display and entertainment functions. It often integrates multiple functions, such as navigation, audio playback, telephone communication, and vehicle status monitoring. Real-vehicle testing is a crucial step in the VIS debugging process. During this phase, engineers load the VIS software into the system and conduct comprehensive testing to verify its stability and reliability, optimize performance, and repair faults. Currently, some technologies rely on manual methods to export and analyze log files from the real-vehicle testing phase to pinpoint faults in the VIS; however, the accuracy of fault location in this method needs improvement. Summary of the Invention

[0003] This application provides a method, apparatus, and vehicle for locating faults in vehicle infotainment systems, which can improve the accuracy of fault location in vehicle infotainment systems during real vehicle testing.

[0004] On the one hand, embodiments of this application provide a method for locating faults in a vehicle infotainment system, including the following steps:

[0005] A real-vehicle test is conducted on the vehicle's infotainment system to obtain the execution stacks of each scheduling link of the infotainment system; wherein, different scheduling links are links connecting different architecture layers of the infotainment system, and the execution stacks of the scheduling links are used to store multiple function calls and multiple variable values ​​of the scheduling links during the real-vehicle test;

[0006] Anomaly detection is performed on the vehicle infotainment system to obtain anomaly detection results, which are used to characterize whether there are any anomalies in the vehicle infotainment system during real vehicle testing.

[0007] If the anomaly detection result indicates that the vehicle system is abnormal during the actual vehicle test, then the abnormal function and abnormal variable value in the vehicle system are determined according to the execution stack of each scheduling link.

[0008] On the other hand, embodiments of this application provide a vehicle infotainment system fault location device, including:

[0009] The first processing module is used to perform real-vehicle testing on the vehicle's infotainment system and obtain the execution stacks of each scheduling link of the infotainment system; wherein, the different scheduling links are links connecting different architecture layers of the infotainment system, and the execution stacks of the scheduling links are used to store multiple function calls and multiple variable values ​​of the scheduling links during the real-vehicle testing.

[0010] The second processing module is used to perform anomaly detection on the vehicle infotainment system and obtain anomaly detection results. The anomaly detection results are used to characterize whether there are any anomalies in the vehicle infotainment system during real vehicle testing.

[0011] The third processing module is used to determine the abnormal function and abnormal variable value in the vehicle system based on the execution stack of each scheduling link if the anomaly detection result indicates that the vehicle system has an anomaly during the actual vehicle test.

[0012] In another aspect, embodiments of this application provide a vehicle, including:

[0013] At least one processor;

[0014] At least one memory for storing at least one program;

[0015] When the at least one program is executed by the at least one processor, the at least one processor implements the above-described vehicle system fault location method.

[0016] The beneficial effects of this application are as follows: It provides a method, apparatus, and vehicle for locating faults in a vehicle infotainment system. First, a real-vehicle test is conducted on the vehicle's infotainment system to obtain the execution stacks of each scheduling link of the system. Different scheduling links are links connecting different architectural layers of the system. The execution stacks of the scheduling links are used to store multiple functional functions and multiple variable values ​​of the scheduling links during the real-vehicle test. Then, anomaly detection is performed on the system to obtain anomaly detection results. These results characterize whether anomalies exist in the system during the real-vehicle test. Finally, if the anomaly detection results indicate that anomalies exist in the system during the real-vehicle test, the functional functions and variable values ​​with anomalies in the system are determined based on the execution stacks of each scheduling link. This application embodiment disassembles and monitors the parameters of each architecture layer of the vehicle infotainment system during real-vehicle testing, obtaining multiple functional functions and multiple variable values ​​of each scheduling link and storing them in the execution stack of each scheduling link. Then, when an anomaly is detected in the vehicle infotainment system during real-vehicle testing, the abnormal functional functions and abnormal variable values ​​in the vehicle infotainment system are quickly and accurately located based on the execution stack of each scheduling link, thereby improving the fault location accuracy and efficiency of the vehicle infotainment system during the real-vehicle testing phase.

[0017] Other features and advantages of this application will be set forth in the description which follows, and will be apparent in part from the description, or may be learned by practicing the application. The objectives and other advantages of this application may be realized and obtained by means of the structures particularly pointed out in the description, claims and drawings. Attached Figure Description

[0018] Figure 1 This is a flowchart of the vehicle infotainment system fault location method provided in this application;

[0019] Figure 2 This is a structural example diagram of the vehicle infotainment system provided in this application;

[0020] Figure 3 This is a structural example diagram of the modified first sub-stack provided in this application;

[0021] Figure 4 This is a structural example diagram of the execution stack provided in this application;

[0022] Figure 5 This is a structural diagram of the vehicle infotainment system fault location device provided in this application;

[0023] Figure 6 This is an example image of the vehicle provided in this application. Detailed Implementation

[0024] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0025] The present application will be further described below with reference to the accompanying drawings and specific embodiments. The described embodiments should not be considered as limitations on the present application, and all other embodiments obtained by those skilled in the art without inventive effort are within the scope of protection of the present application.

[0026] In the following description, references are made to “some embodiments,” which describe a subset of all possible embodiments. However, it is understood that “some embodiments” may be the same subset or different subsets of all possible embodiments and may be combined with each other without conflict.

[0027] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used herein is for the purpose of describing embodiments of this application only and is not intended to limit this application.

[0028] A vehicle infotainment system (VIS) refers to an electronic system installed in a vehicle to provide information display and entertainment functions. It often integrates multiple VIS functions, such as navigation, audio playback, telephone communication, and vehicle status monitoring. VIS debugging is an indispensable and crucial part of the vehicle development process. It can be divided into two stages: cockpit bench testing and real-vehicle testing. The cockpit bench testing stage simulates various driving conditions, while the real-vehicle testing stage more closely resembles actual driving conditions.

[0029] During the cockpit bench testing phase, testing personnel load the vehicle infotainment system's software program into the cockpit bench environment. Using tools such as debuggers and monitors, they monitor the software program's execution, variable values, and the vehicle system's status in real time to verify the software program's correctness and performance. This allows testing personnel to identify and fix potential problems with the software program, ensuring its stable operation in actual vehicle infotainment systems.

[0030] During the real-vehicle testing phase, testing personnel load the in-vehicle infotainment software into the system and conduct comprehensive testing, including aspects such as user interface interaction, data processing, and response speed. This verifies the stability and reliability of the system and optimizes and adjusts its performance. In this way, testing personnel can identify and fix issues related to vehicle hardware and environmental compatibility, further ensuring the stable operation of the in-vehicle software in actual in-vehicle systems.

[0031] In related technologies, log files from the actual vehicle testing phase are obtained. These log files typically record operational details of the vehicle's infotainment system, such as operation logs, time records, and error messages. These log files are then manually analyzed to pinpoint faults in the infotainment system. However, these technologies rely on manual methods, and the accuracy and efficiency of fault location for the infotainment system need improvement.

[0032] In view of this, embodiments of this application provide a method, apparatus and vehicle for locating faults in vehicle infotainment systems, aiming to improve the accuracy and efficiency of fault location in vehicle infotainment systems during the real vehicle testing phase.

[0033] The specific implementation methods of the embodiments of this application will be described in detail below with reference to the accompanying drawings. First, the implementation steps of the vehicle system fault location method provided in the embodiments of this application will be described with reference to the accompanying drawings.

[0034] The vehicle-mounted system fault location method provided in this application can be applied to terminals, servers, or software running on either terminal or server. Terminals can be tablets, laptops, desktop computers, etc., but are not limited to these. Servers can be independent physical servers, server clusters or distributed systems composed of multiple physical servers, or cloud servers providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, content delivery networks (CDNs), and big data and artificial intelligence platforms. Furthermore, a server can be a node server in a blockchain network, but is not limited to these. Blockchain is a new application model of computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanisms, and encryption algorithms.

[0035] Reference Figure 1 The fault location method for this vehicle infotainment system mainly includes the following steps S101-S103:

[0036] S101, Conduct a real-vehicle test on the vehicle's infotainment system to obtain the execution stacks of each scheduling link of the infotainment system; where different scheduling links are links connecting different architecture layers of the infotainment system, and the execution stacks of the scheduling links are used to store multiple function calls and multiple variable values ​​of the scheduling links during the real-vehicle test.

[0037] S102, Perform anomaly detection on the vehicle infotainment system and obtain anomaly detection results. The anomaly detection results are used to characterize whether there are any anomalies in the vehicle infotainment system during real vehicle testing.

[0038] S103, if the anomaly detection result indicates that there is an anomaly in the vehicle infotainment system during the actual vehicle test, then the abnormal function and abnormal variable value in the vehicle infotainment system are determined according to the execution stack of each scheduling link.

[0039] In this embodiment, firstly, a real-vehicle test is performed on the vehicle's infotainment system to obtain the execution stacks of each scheduling link of the infotainment system. Different scheduling links are links connecting different architectural layers of the infotainment system. The execution stacks of the scheduling links are used to store multiple functional functions and multiple variable values ​​of the scheduling links during the real-vehicle test. Then, anomaly detection is performed on the infotainment system to obtain anomaly detection results. These results characterize whether any anomalies exist in the infotainment system during the real-vehicle test. Finally, if the anomaly detection results indicate that anomalies exist in the infotainment system during the real-vehicle test, the functional functions and variable values ​​with anomalies in the infotainment system are determined based on the execution stacks of each scheduling link. Therefore, this application embodiment disassembles and monitors the parameters of each architectural layer of the vehicle infotainment system during real-vehicle testing, obtains multiple functional functions and multiple variable values ​​of each scheduling link, and stores them in the execution stack of each scheduling link. Then, when an anomaly is detected in the vehicle infotainment system during real-vehicle testing, the abnormal functional functions and abnormal variable values ​​in the vehicle infotainment system can be quickly and accurately located based on the execution stack of each scheduling link. This facilitates the troubleshooting of the corresponding faults in the vehicle infotainment system, effectively improves the response speed of fault diagnosis and system repair of the vehicle infotainment system, and improves the fault location accuracy and efficiency of the vehicle infotainment system during the real-vehicle testing phase.

[0040] In step S101 above, the vehicle's infotainment system is tested in a real vehicle. During the real vehicle test, the architecture layers of the infotainment system are disassembled and parameters are monitored to obtain multiple function and variable values ​​of each scheduling link and store them in the execution stack of each scheduling link.

[0041] The aforementioned scheduling links are used to connect the various architectural layers of the vehicle infotainment system. Different scheduling links are links connecting different architectural layers of the vehicle infotainment system, and all scheduling links together reflect the execution process of the vehicle infotainment system's software program.

[0042] The architecture layers of the above-mentioned vehicle infotainment system can be set according to the actual situation. This application embodiment does not limit this. For example, the architecture layers of the above-mentioned vehicle infotainment system may include the transmission layer, the system layer and the application layer, but are not limited to this.

[0043] The execution stack of the aforementioned scheduling link can refer to a stack. A stack is a linear list where insertion and deletion operations can only be performed at one end, called the top of the stack, and the other end called the bottom of the stack. A stack is characterized by Last-In-First-Out (LIFO), meaning the last element pushed onto the stack is the first element popped off, and the first element pushed onto the stack is the last element popped off.

[0044] The execution stack of the aforementioned scheduling link is used to store multiple function calls and variable values ​​of the scheduling link during real vehicle testing. These function calls and variable values ​​are used to execute the vehicle infotainment system's functions to ensure the normal operation of the vehicle infotainment system.

[0045] The above-mentioned function and variable values ​​can be set according to the actual situation, and the embodiments of this application do not limit them.

[0046] For example, the functional functions of the framework layer in the vehicle infotainment system may include navigation function functions, radio function functions, voice function functions, etc. Among them, the navigation function function is used to implement the navigation function of the vehicle infotainment system, the radio function function is used to implement the radio function of the vehicle infotainment system, and the voice function function is used to implement the voice control function of the vehicle infotainment system. Each function function can be configured with one or more variable values. Variable values ​​can be understood as the input values ​​and / or output values ​​of the function function, but are not limited to this.

[0047] The above-mentioned real-vehicle testing of the vehicle's infotainment system to obtain the execution stack of each scheduling link of the infotainment system may include loading the infotainment software program into the infotainment system and testing the infotainment system to obtain real-vehicle test log data. Then, parameters are extracted from the real-vehicle test log data to obtain multiple function and variable values ​​of each scheduling link during the real-vehicle test and randomly pushed into the corresponding execution stack to obtain the execution stack of each scheduling link, but it is not limited to this.

[0048] In step S102 above, after the actual vehicle test is completed, the vehicle infotainment system is subjected to anomaly detection. The purpose is to detect whether there are any anomalies in the vehicle infotainment system during the actual vehicle test, and then obtain the anomaly detection results to realize the anomaly detection of the vehicle infotainment system.

[0049] The above anomaly detection results are used to characterize whether there are any anomalies in the vehicle infotainment system during real vehicle testing.

[0050] The above-mentioned anomaly detection of the vehicle infotainment system and the resulting anomaly detection results may include obtaining the number of errors during the actual vehicle test. If the number of errors is greater than the preset error threshold, the anomaly detection result is determined to be that there is an anomaly in the vehicle infotainment system during the actual vehicle test; otherwise, the anomaly detection result is determined to be that there is no anomaly in the vehicle infotainment system during the actual vehicle test, but it is not limited to this.

[0051] The above-mentioned error threshold can be set according to the actual situation. This application embodiment does not make specific limitations on this. For example, the above-mentioned error threshold can be zero, but it is not limited to this.

[0052] In step S103 above, after anomaly detection is completed, if the anomaly detection result indicates that the vehicle infotainment system is abnormal during the actual vehicle test, it means that the vehicle infotainment system is abnormal during the actual vehicle test. At this time, it is necessary to locate and handle the problem in the vehicle infotainment system. Specifically, since the functional functions and variable values ​​of each scheduling link can coordinate to achieve one or more vehicle infotainment functions, if a certain functional function is abnormal and / or a certain variable value is abnormal, it may cause the vehicle infotainment function to fail to be implemented, thereby causing the vehicle infotainment system to be abnormal. Therefore, when the vehicle infotainment system is abnormal, this application embodiment quickly and accurately locates the abnormal functional function and abnormal variable value based on multiple functional functions and multiple variable values ​​of each scheduling link, thereby realizing the fault location and handling of the vehicle infotainment system.

[0053] The above-mentioned method of determining abnormal functional functions and abnormal variable values ​​in the vehicle system based on the execution stack of each scheduling link may include popping the execution stack of each scheduling link to obtain multiple functional functions and multiple variable values ​​of the scheduling link, and then using machine learning methods to detect the multiple functional functions and multiple variable values ​​to obtain the detection results of each functional function and each variable value. The detection results include either normal results or abnormal results. Functional functions with abnormal detection results are considered as abnormal functional functions in the vehicle system, and variable values ​​with abnormal detection results are considered as abnormal variable values ​​in the vehicle system, but it is not limited to this.

[0054] The machine learning methods described above can be set according to actual conditions, and the embodiments of this application do not limit them. For example, the machine learning method described above can be a support vector machine; or, the machine learning method described above can be logistic regression, but is not limited to this.

[0055] The steps described above will be explained in further detail below.

[0056] In some implementations, the above-mentioned vehicle system may contain at least one of the following scheduling links:

[0057] The first link is used to characterize the link from the framework layer of the vehicle system to the system layer of the vehicle system.

[0058] The second link is used to characterize the link from the system layer to the framework layer;

[0059] The third link is used to characterize the link from the framework layer to the application layer of the vehicle system;

[0060] The fourth link is used to characterize the link from the application layer to the framework layer;

[0061] The framework layer is configured with multiple service classes, each corresponding to at least one vehicle infotainment function of the vehicle infotainment system. The system layer is used to encapsulate the bus signals of each service class into corresponding service interfaces and return them to the framework layer. The framework layer is used to provide the service interfaces of each service class to the application layer. When the vehicle infotainment function of the vehicle infotainment system is triggered, the application layer is used to call the service class corresponding to the triggered vehicle infotainment function through the service interface of the service class corresponding to the triggered vehicle infotainment function. The framework layer is used to execute the service class corresponding to the triggered vehicle infotainment function.

[0062] In this embodiment, the vehicle infotainment system may include a framework layer, a system layer, and an application layer, such as... Figure 2 The diagram shown is an example of the structure of a vehicle infotainment system. The framework layer can be configured with multiple service classes, each corresponding to one or more vehicle infotainment functions. For example, the framework layer is configured with multiple service classes such as an external controller status display and setting service class and a navigation and entertainment service class. The external controller status display and setting service class can correspond to vehicle infotainment functions such as air conditioning settings, charging settings, and vehicle settings, while the navigation and entertainment service class can correspond to vehicle infotainment functions such as navigation, music, video, and radio.

[0063] When the vehicle infotainment system starts up, the system layer receives bus signals from various service classes, encapsulates these signals into corresponding service interfaces, and returns them to the framework layer. The framework layer receives these service interfaces and provides them to the application layer. When a vehicle infotainment function is triggered, the application layer calls the corresponding service class through its service interface, enabling the framework layer to execute the service class and thus implement the triggered function.

[0064] It should be noted that the functions of the framework layer, system layer and application layer of the above-mentioned vehicle system are not limited to the above contents. The functions of the framework layer, system layer and application layer can be configured according to the actual situation, and this embodiment does not make specific limitations on this.

[0065] Based on this, this embodiment defines that the vehicle infotainment system can have at least one of the following scheduling links: a first link, a second link, a third link, and a fourth link. Specifically, the first link is the link from the framework layer to the system layer. The framework layer transmits the bus signals of each service class to the system layer through the first link, so that the system layer receives the bus signals of each service class and completes the interface encapsulation operation. The second link is the link from the system layer to the framework layer. The system layer transmits the encapsulated service interfaces to the framework layer through the second link, so that the framework layer receives the service interfaces of each service class. The third link is the link from the framework layer to the application layer. The framework layer provides the service interfaces of each service class to the application layer through the third link. The fourth link is the link from the application layer to the framework layer. In the fourth link, the application layer calls the service class corresponding to the triggered vehicle infotainment function in the framework layer through the service interface of the service class corresponding to the triggered vehicle infotainment function. Then, the framework layer executes the service class corresponding to the triggered vehicle infotainment function, thereby realizing the triggered vehicle infotainment function.

[0066] The first, second, and third links together reflect the processing status of the service interfaces of each service class. If the service interface of a service class is encapsulated abnormally, or if the service interface of a service class cannot be passed to the framework layer or application layer, it will affect the application layer's call to the service class, thus preventing the corresponding vehicle infotainment function from being implemented and causing the vehicle infotainment system to malfunction. The fourth link reflects the implementation status of the vehicle infotainment function. If the service interface call is abnormal, or the service class execution is abnormal, it will affect the normal implementation of the vehicle infotainment function and cause the vehicle infotainment system to malfunction.

[0067] As can be seen, this implementation introduces the concept of a layered architecture, utilizing the hierarchical relationship of the various architectural layers of the vehicle infotainment system to decompose the system into a first link, a second link, a third link, and a fourth link. The first, second, and third links reflect the service interface processing status of the vehicle infotainment system, while the fourth link reflects the implementation status of the vehicle infotainment functions. This facilitates the monitoring of parameters of different levels of scheduling links during real vehicle testing and enables fault location and handling of the vehicle infotainment system after real vehicle testing by using the parameters of different levels of scheduling links.

[0068] The types of the aforementioned service classes can be set according to actual circumstances, and this implementation method does not impose specific limitations on them. For example, the types of the aforementioned service classes can be external controller status display and setting service classes, navigation and entertainment service classes, and controller proxy service classes, etc. Among them, the external controller status display and setting service class is mainly used to realize vehicle system functions such as air conditioning settings, charging settings, vehicle settings, and digital video recording; the navigation and entertainment service class is mainly used to realize vehicle system functions such as navigation, music, video, and radio; and the controller proxy service class is mainly used to realize vehicle system functions such as rearview mirror control and amplifier control, but is not limited to these.

[0069] The type of the service interface can be set according to the actual situation. This implementation does not limit it in any specific way. For example, the service interface can be an application programming interface (API), but it is not limited to this.

[0070] In some implementations, the above-mentioned real-vehicle testing of the vehicle's infotainment system to obtain the execution stacks of each scheduling link of the infotainment system may include:

[0071] Load the preset in-vehicle software program into the in-vehicle system;

[0072] Real-vehicle testing was conducted on the in-vehicle infotainment system loaded with the in-vehicle infotainment software program;

[0073] For each scheduling link in the vehicle system, the execution stack of the scheduling link is obtained based on multiple function and variable values ​​of the scheduling link during the actual vehicle test.

[0074] In this embodiment, firstly, the vehicle infotainment software program is loaded into the vehicle infotainment system. This software program is a pre-set program that is mainly used to implement various vehicle infotainment functions. Then, the vehicle infotainment system with the loaded software program is subjected to real-vehicle testing. During the real-vehicle testing, for each scheduling link in the vehicle infotainment system, multiple function names and multiple variable values ​​are obtained. Based on these function names and variable values, the execution stack of the scheduling link is constructed. This facilitates the quick and accurate location of abnormal function names and abnormal variable values ​​in the vehicle infotainment system when an anomaly is detected in the vehicle infotainment system during the real-vehicle testing, by using the execution stack of each scheduling link.

[0075] The above-mentioned vehicle infotainment software program can be set according to actual conditions, and this implementation method does not impose specific limitations on it.

[0076] The execution stack of the scheduling link is obtained based on multiple function calls and multiple variable values ​​during real vehicle testing. This can include marking the called function call onto the stack when a function call is made, and marking the triggered variable value onto the stack when a variable value is triggered. The order in which function calls and variable values ​​are pushed onto the stack is positively correlated with the time value. That is, the earlier the time value when a function call is made or a variable value is triggered, the earlier the function call or variable value is pushed onto the stack. However, this is not the only factor.

[0077] In some implementations, obtaining the execution stack of the scheduling link based on multiple function calls and multiple variable values ​​during real-vehicle testing may include:

[0078] Push multiple function calls of the scheduling link onto the first sub-stack of the scheduling link;

[0079] Push multiple variable values ​​from the scheduling link into the second sub-stack of the scheduling link;

[0080] The execution stack of the scheduling link is obtained based on the first and second sub-stacks.

[0081] In this embodiment, during real vehicle testing, for each scheduling link in the vehicle infotainment system, multiple function calls of the scheduling link are pushed onto the first sub-stack of the scheduling link, and multiple variable values ​​of the scheduling link are pushed onto the second sub-stack corresponding to the scheduling link. Then, the execution stack of the scheduling link is constructed using the first and second sub-stacks. By storing the corresponding function calls in the first sub-stack and the corresponding variable values ​​in the second sub-stack, it is beneficial to quickly traverse each function call and variable value when performing fault location processing on the vehicle infotainment system, thereby quickly and accurately locating the abnormal function calls and abnormal variable values ​​in the vehicle infotainment system.

[0082] The first sub-stack of the aforementioned scheduling link is used to store multiple function calls of the scheduling link.

[0083] The above-mentioned pushing multiple function calls of the scheduling link onto the first sub-stack of the scheduling link can include pushing multiple function calls of the scheduling link onto the first sub-stack of the scheduling link in sequence according to the scheduling time value of the function call. The order of pushing the function call onto the stack is positively correlated with the scheduling time value, that is, the earlier the scheduling time value of the function call, the earlier the function call is pushed onto the first sub-stack.

[0084] Alternatively, the above-mentioned pushing multiple function calls of the scheduling link onto the first sub-stack of the scheduling link may include pushing multiple function calls of the scheduling link onto the first sub-stack of the scheduling link in sequence according to the scheduling time value of the function calls, wherein the order of pushing function calls onto the stack is negatively correlated with the scheduling time value, that is, the earlier the scheduling time value of the function call, the later the order of pushing function call into the first sub-stack.

[0085] It should be understood that if multiple function calls are pushed onto the stack at the same scheduling time value, the order in which these functions are pushed onto the stack can be random.

[0086] The second sub-stack of the aforementioned scheduling link is used to store multiple variable values ​​of the scheduling link.

[0087] The above-mentioned pushing multiple variable values ​​of the scheduling link into the second sub-stack of the scheduling link may include pushing multiple variable values ​​of the scheduling link into the second sub-stack of the scheduling link in sequence according to the trigger time value of the variable value. The push order of the variable value is positively correlated with the trigger time value, that is, the earlier the trigger time value of the variable value, the earlier the push order of the variable value in the second sub-stack.

[0088] Alternatively, the above-mentioned pushing multiple variable values ​​of the scheduling link into the second sub-stack of the scheduling link may include pushing multiple variable values ​​of the scheduling link into the second sub-stack of the scheduling link in sequence according to the trigger time value of the variable value, wherein the push order of the variable value is negatively correlated with the trigger time value, that is, the earlier the trigger time value of the variable value, the later the push order of the variable value in the second sub-stack.

[0089] Optionally, if multiple variable values ​​are pushed onto the stack at the same trigger time value, the order in which these multiple variable values ​​are pushed onto the stack at the same trigger time value can be random.

[0090] The execution stack described above may include a first sub-stack and a second sub-stack, but is not limited to these.

[0091] The execution stack of the scheduling link obtained above based on the first sub-stack and the second sub-stack may include concatenating the first sub-stack and the second sub-stack into the execution stack of the scheduling link. In the execution stack, the first sub-stack and the second sub-stack are independent of each other, but are not limited to this.

[0092] In some implementations, obtaining the execution stack of the scheduling link based on the first sub-stack and the second sub-stack may include:

[0093] For each function in the first substack, based on the substack mapping data, at least one variable value corresponding to the function in the second substack is determined as the target variable value of the function. Based on the arrangement position of the function in the first substack and the arrangement position of each target variable value in the second substack, the mapping identifier of the function relative to each target variable value is obtained as an element of the mapping set of the function. The substack mapping data includes multiple preset function functions and at least one variable value corresponding to each preset function.

[0094] The first substack is modified by using the mapping set of each function of the first substack to obtain the modified first substack;

[0095] Based on the second sub-stack and the modified first sub-stack, construct the execution stack of the scheduling link.

[0096] In this embodiment, for each scheduling link, when a function is scheduled, one or more variable values ​​corresponding to that function will be triggered synchronously. That is, a function corresponds to one or more variable values, which can be understood as the input and output values ​​of the function. Based on this, this embodiment maps each function in the first sub-stack and each variable value in the second sub-stack to obtain the execution stack of the scheduling link. By constructing the mapping relationship between the first and second sub-stacks, each function in the vehicle system is strongly correlated with its corresponding variable value. This facilitates the rapid traversal of each function and variable value when performing fault location processing on the vehicle system, thereby quickly and accurately locating the abnormal function and the abnormal variable value.

[0097] Specifically, firstly, for each function in the first substack, based on the substack mapping data, at least one variable value corresponding to the function is determined in the second substack as the target variable value of the function. Then, based on the arrangement position of the function in the first substack and the arrangement position of each target variable value in the second substack, mapping identifiers of the function relative to each target variable value are determined as elements of the function's mapping set. Each mapping identifier reflects the relationship between the function and each variable value. It can be understood that these elements collectively constitute the function's mapping set. By traversing each function in the first substack, the mapping set of each function in the first substack can be obtained. Next, the first substack is modified using the mapping set of each function, resulting in a modified first substack. This modification can be understood as assigning the mapping set of each function to each function, so that each function carries the corresponding mapping set during pop processing, thus facilitating the lookup of the corresponding variable value through the mapping set of each function. Finally, based on the second substack and the modified first substack, the execution stack of the scheduling chain is constructed.

[0098] The substack mapping data mentioned above may include multiple preset function names and at least one variable value corresponding to each preset function name.

[0099] The data format of the sub-stack mapping data can be set according to the actual situation. This implementation does not limit it. For example, the sub-stack mapping data can be chart data or table data, but it is not limited to this.

[0100] The mapping relationship between the above-mentioned function and the above-mentioned variable value can be set according to the actual situation, and this implementation method does not limit it.

[0101] The above-mentioned method, based on the arrangement position of the function in the first sub-stack and the arrangement position of each target variable value in the second sub-stack, obtains the mapping identifier of the function relative to each target variable value. This can include associating the arrangement position of the function in the first sub-stack with the arrangement position of the target variable value in the second sub-stack for each target variable value to obtain the mapping identifier of the function relative to the target variable value; wherein, the first The first sub-stack of the scheduling link The function is relative to the first The second sub-stack of the scheduling link The mapping identifier for each target variable value can be represented as (the arrangement position of the function in the first substack). The position of the target variable value in the second substack ).

[0102] Alternatively, the above method of obtaining the mapping identifier of the function relative to each target variable value based on the arrangement position of the function in the first sub-stack and the arrangement position of each target variable value in the second sub-stack can include associating the arrangement position of the function in the first sub-stack with the arrangement position of the target variable value in the second sub-stack for each target variable value to obtain the mapping identifier of the function relative to the target variable value; wherein, the first The first sub-stack of the scheduling link The function is relative to the first The second sub-stack of the scheduling link The mapping identifier for each target variable value can be represented as (the position of the target variable value in the second substack). The arrangement of functions in the first substack ).

[0103] The mapping set of the above-mentioned function can include multiple elements, where each element is a mapping identifier of the function relative to the value of the target variable.

[0104] The above-mentioned modification of the first sub-stack using the mapping set of each function of the first sub-stack can be achieved by assigning the mapping set of each function to the function, so that the function carries the corresponding mapping set during the pop operation.

[0105] The above-mentioned execution stack for constructing the scheduling link based on the second sub-stack and the modified first sub-stack can be achieved by concatenating the second sub-stack and the modified first sub-stack into the execution stack of the scheduling link. In the execution stack, the first sub-stack and the second sub-stack are interconnected through the mapping set of each function.

[0106] In one example, the first sub-stack of a certain scheduling link sequentially pushes function A, function B, function C, function D, ..., function Y. Since function A is pushed onto the stack first, the bottom pointer of the first sub-stack points to function A, and since function Y is pushed onto the stack last, the top pointer of the first sub-stack points to function Y. Similarly, the second sub-stack sequentially pushes variable value A, variable value B, variable value C, variable value D, ..., variable value X. Since variable value A is pushed onto the stack first, the bottom pointer of the second sub-stack points to variable value A, and since variable value X is pushed onto the stack last, the bottom pointer of the second sub-stack points to variable value X.

[0107] Taking function A, function B, function C, function D, and function Y as examples, assuming that through substack mapping data, function A is associated with variable value A and variable value B respectively, function B is associated with variable value C, function C is associated with variable value B, function D is associated with variable value D, and function Y is associated with variable value X, based on this, the mapping identifiers of function A relative to variable value A and function A relative to variable value B are determined as elements of mapping set 1 of function A, thus constructing mapping set 1 of function A; and function B is determined... The mapping identifier relative to the variable value C is used as an element of the mapping set 2 of the function B, thus constructing the mapping set 2 of the function B; the mapping identifier of the function C relative to the variable value B is determined as an element of the mapping set 3 of the function C, thus constructing the mapping set 3 of the function C; the mapping identifier of the function D relative to the variable value D is determined as an element of the mapping set 4 of the function D, thus constructing the mapping set 4 of the function D; the mapping identifier of the function Y relative to the variable value X is determined as an element of the mapping set N of the function Y, thus constructing the mapping set N of the function Y.

[0108] After obtaining the mapping sets for each function, mapping set 1 is assigned to function A, mapping set 2 to function B, mapping set 3 to function C, mapping set 4 to function D, and mapping set N to function Y. This yields the modified first sub-stack. Figure 3 As shown. Finally, the second sub-stack and the modified first sub-stack are concatenated to form the execution stack of the scheduling chain. In the execution stack, the first and second sub-stacks are interconnected through the mapping sets of various function calls, as shown below. Figure 4 As shown.

[0109] In some implementations, the above-mentioned anomaly detection of the vehicle infotainment system to obtain anomaly detection results may include:

[0110] Obtain real-vehicle test log data from the vehicle infotainment system;

[0111] Based on the actual vehicle test log data, anomaly detection was performed on each scheduling link;

[0112] If at least one scheduling link is detected as abnormal, the abnormality detection result is determined to be an anomaly in the vehicle system during the actual vehicle test.

[0113] In this embodiment, after completing the real-vehicle testing, anomaly detection needs to be performed on the vehicle infotainment system, that is, to detect whether there are any anomalies in the vehicle infotainment system during the real-vehicle testing. Specifically, firstly, the real-vehicle test log data of the vehicle infotainment system is acquired. The real-vehicle test log data is used to characterize the scheduling status of each scheduling link during the real-vehicle testing. Then, based on the real-vehicle test log data, anomalies are detected in each scheduling link. If at least one scheduling link is detected to be abnormal, it indicates that there is an anomaly in the vehicle infotainment system during the real-vehicle testing. At this point, the anomaly detection result is determined to be that there is an anomaly in the vehicle infotainment system during the real-vehicle testing, thus improving the anomaly detection efficiency of the vehicle infotainment system.

[0114] The acquisition of real-vehicle test log data of the vehicle infotainment system mentioned above may include capturing real-vehicle test log data of the vehicle infotainment system through a preset log management tool, but is not limited to this.

[0115] The log management tool described above can be configured according to actual needs, and this implementation method does not limit it. For example, the log management tool described above can be Logcat from Android Studio; or, the log management tool described above can be a third-party tool such as Bugfender or ACRA, but it is not limited to these.

[0116] The above-mentioned anomaly detection of each scheduling link based on real vehicle test log data may include processing the real vehicle test log data using natural language processing technology to obtain the log events of each scheduling link, and then using machine learning methods to detect anomalies of each scheduling link based on the log events of each scheduling link, but is not limited to this.

[0117] The machine learning methods described above can be set according to the actual situation, and the embodiments of this application do not limit them.

[0118] For example, the machine learning method described above could be a support vector machine; or, the machine learning method described above could be logistic regression, but it is not limited to these.

[0119] In some implementations, the above-mentioned anomaly detection of each scheduling link based on real vehicle test log data may include:

[0120] Based on the actual vehicle test log data, the link parameters were obtained;

[0121] The link parameters include first interface parameters, second interface parameters, third interface parameters, interface scheduling parameters, service class execution status, packet loss rate of the first link, packet loss rate of the second link, and packet loss rate of the third link. The first interface parameters are the parameters of the service interface encapsulated by the system layer, the second interface parameters are the parameters of the service interface received by the framework layer, the third interface parameters are the parameters of the service interface received by the application layer, the interface scheduling parameters are the parameters of the service interface called by the application layer, and the service class execution status includes either a success status or a failure status.

[0122] The above-mentioned anomaly detection of each scheduling link based on real vehicle test log data may also include at least one of the following:

[0123] Based on the packet loss rate of the first link, perform anomaly detection on the first link;

[0124] Based on the first interface parameters, the second interface parameters, and the packet loss rate of the second link, anomaly detection is performed on the second link;

[0125] Based on the parameters of the second interface, the parameters of the third interface, and the packet loss rate of the third link, anomaly detection is performed on the third link;

[0126] Based on the interface scheduling parameters and the execution status of the service class, anomaly detection is performed on the fourth link.

[0127] In this embodiment, after acquiring the real vehicle test log data, the real vehicle test log data is first processed to obtain link parameters. The link parameters may include first interface parameters, second interface parameters, third interface parameters, interface scheduling parameters, service execution status, packet loss rate of the first link, packet loss rate of the second link, and packet loss rate of the third link. Then, based on one or more data in the link parameters and combined with the characteristics of each scheduling link, anomaly detection is performed on each scheduling link, which can effectively improve the anomaly detection accuracy of each scheduling link.

[0128] Specifically, the framework layer transmits the bus signals of each service class to the system layer through the first link, enabling the system layer to receive and encapsulate the bus signals of each service class. If some service class bus signals are lost during transmission through the first link, the system layer cannot encapsulate the interfaces of the service classes with missing bus signals, leading to malfunctions in the vehicle infotainment system. Therefore, the integrity of the transmission of bus signals for each service class is crucial for the stable operation of the vehicle infotainment system. Thus, the packet loss rate of the first link can be used to detect anomalies in the first link, specifically whether bus signals for each service class are lost during transmission.

[0129] The system layer transmits the encapsulated service interfaces to the framework layer via a second link. If the service interfaces encapsulated by the system layer are abnormal, or if some service interfaces of certain service classes are lost during transmission through the second link, it will affect subsequent application layer calls to the service interfaces and the implementation of vehicle infotainment functions, leading to vehicle infotainment system malfunctions. Specifically, an abnormal encapsulated service interface at the system layer can be understood as the system layer encapsulating the bus signals of a service class into an incorrect service interface. Therefore, the accuracy of interface encapsulation at the system layer and the integrity of the transmission of service interfaces of each service class are crucial for the stable operation of the vehicle infotainment system. Thus, anomaly detection of the second link can be performed by analyzing the parameters of the service interfaces encapsulated by the system layer, the parameters of the service interfaces received by the framework layer, and the packet loss rate of the second link. This allows for the detection of whether the interface encapsulation operation of the system layer is abnormal and whether service interfaces of various service classes are lost in the second link.

[0130] The framework layer provides service interfaces for each service class to the application layer via a third-party link. If some service interfaces are lost during transmission through this third link, it will affect subsequent application layer calls to the service interfaces and the implementation of vehicle infotainment functions, leading to system malfunctions. Therefore, the integrity of the transmission of service interfaces for each service class is crucial for the stable operation of the vehicle infotainment system. Thus, anomaly detection can be performed on the second link by analyzing the parameters of the service interfaces received by the framework layer, the parameters of the service interfaces received by the application layer, and the packet loss rate of the third link, to detect whether service interfaces for each service class are lost in the third link.

[0131] In the fourth link, the application layer calls the corresponding service class in the framework layer through the service interface of the service class corresponding to the triggered vehicle infotainment function. The framework layer then executes the service class corresponding to the triggered vehicle infotainment function. If the service interface call is abnormal, or if the service interface call is normal but the service class execution is abnormal, the vehicle infotainment function may fail to function, leading to vehicle infotainment system malfunctions. An abnormal service interface call can be understood as the application layer calling a service interface that does not correspond to the triggered vehicle infotainment function. Therefore, the correctness of the service interface calls and the correctness of the service class execution are crucial for the stable operation of the vehicle infotainment system. Thus, anomaly detection in the fourth link can be performed by checking the parameters of the service interfaces called by the application layer and the state of the service class corresponding to the triggered vehicle infotainment function to verify whether the service interfaces are called correctly and whether the service classes are executed correctly.

[0132] The packet loss rate mentioned above can be the ratio of the difference in packet volume between the receiver and the sender to the packet volume received by the receiver. The difference in packet volume between the receiver and the sender can be the absolute value of the difference between the packet volume received by the receiver and the packet volume sent by the sender.

[0133] The above-mentioned anomaly detection of the first link based on the packet loss rate can include performing anomaly detection of the first link based on the packet loss rate of the first link in combination with machine learning methods, and obtaining the anomaly detection result of the first link.

[0134] Alternatively, the above-mentioned anomaly detection of the first link based on the packet loss rate of the first link may include determining that the first link is abnormal if the packet loss rate of the first link is greater than a preset first packet loss threshold, otherwise determining that the first link is not abnormal.

[0135] The first packet loss threshold mentioned above can be set according to the actual situation, and this embodiment does not impose specific limitations on it.

[0136] The first interface parameter mentioned above refers to the parameters of the service interface encapsulated at the system layer, such as the type of the service interface encapsulated at the system layer and the vehicle function identifier, etc. The vehicle function identifier can be a specific value, but is not limited to it.

[0137] The second interface parameter mentioned above refers to the parameters of the service interface received by the framework layer, such as the type of service interface received by the framework layer and the vehicle function identifier, but is not limited to these.

[0138] The above-mentioned anomaly detection of the second link based on the first interface parameters, the second interface parameters, and the packet loss rate of the second link may include performing anomaly detection of the second link based on the first interface parameters, the second interface parameters, and the packet loss rate of the second link, combined with machine learning methods, to obtain the anomaly detection result of the second link.

[0139] Alternatively, the above-mentioned anomaly detection of the second link based on the first interface parameters, the second interface parameters, and the packet loss rate of the second link may include determining that the second link is abnormal if at least one of the following is met: the first interface parameters are inconsistent with the preset encapsulation interface parameters, the first interface parameters are inconsistent with the second interface parameters, or the packet loss rate of the second link is greater than the preset second packet loss threshold; otherwise, determining that the second link is not abnormal.

[0140] The aforementioned second packet loss threshold and the aforementioned encapsulation interface parameters can be set according to actual conditions, and this embodiment does not impose specific limitations on them. For example, the aforementioned encapsulation interface parameters may include the preset type and preset function identifier of the service interface, etc., wherein the preset function identifier may be a specific value, but is not limited to this.

[0141] The inconsistency between the aforementioned first interface parameter and the preset encapsulation interface parameter may refer to the fact that the type of the service interface encapsulated at the system layer is different from the preset type of the service interface encapsulated at the system layer, and / or that the vehicle-mounted function identifier of the service interface encapsulated at the system layer is different from the preset function identifier of the service interface encapsulated at the system layer.

[0142] The inconsistency between the first interface parameter and the second interface parameter may refer to the fact that the type of the service interface encapsulated by the system layer is different from the type of the service interface received by the framework layer, and / or that the vehicle function identifier of the service interface encapsulated by the system layer is different from the preset function identifier of the service interface received by the framework layer.

[0143] The aforementioned third interface parameter refers to the parameters of the service interface received by the application layer, such as the type of service interface received by the application layer and the vehicle system function identifier, but is not limited to these.

[0144] The above-mentioned anomaly detection of the third link based on the second interface parameters, the third interface parameters, and the packet loss rate of the third link can include using machine learning methods to perform anomaly detection of the third link based on the second interface parameters, the third interface parameters, and the packet loss rate of the third link, and obtaining the anomaly detection result of the third link.

[0145] Alternatively, the above-mentioned anomaly detection of the third link based on the second interface parameters, the third interface parameters, and the packet loss rate of the third link may include determining that the third link is abnormal if the second interface parameters are inconsistent with the third interface parameters, and / or the packet loss rate of the third link is greater than a preset third packet loss threshold; otherwise, determining that the third link is not abnormal.

[0146] The aforementioned third packet loss threshold can be set according to actual conditions, and this implementation method does not impose specific limitations on it.

[0147] The inconsistency between the second and third interface parameters mentioned above may refer to the different types of service interfaces received by the framework layer and the application layer, and / or the different vehicle-mounted system function identifiers of the service interfaces received by the framework layer and the application layer.

[0148] The aforementioned interface scheduling parameters refer to the parameters of the service interfaces called by the application layer, such as the type of service interface called by the application layer and the vehicle system function identifier, but are not limited to these.

[0149] The above-mentioned service class execution status is mainly used to characterize the status of the service class corresponding to the triggered vehicle infotainment function. The service class execution status includes either a success status or a failure status. The success status indicates that the service class is executed successfully and the vehicle infotainment function is successfully implemented; the failure status indicates that the service class is executed unsuccessfully and the vehicle infotainment function is not successfully implemented.

[0150] The above-mentioned anomaly detection of the fourth link based on interface scheduling parameters and service class execution status can include using machine learning methods to perform anomaly detection of the fourth link based on interface scheduling parameters and service class execution status, and obtaining the anomaly detection result of the fourth link.

[0151] Alternatively, the above-mentioned anomaly detection of the fourth link based on interface scheduling parameters and service class execution status may include determining that the fourth link has an anomaly if the interface scheduling parameters are inconsistent with the preset interface parameters of the triggered vehicle system function, and / or the service class execution status is in a failed state; otherwise, determining that the fourth link does not have an anomaly.

[0152] The preset interface parameters of the triggered vehicle infotainment functions can be set according to actual conditions, and this embodiment does not limit them. For example, the preset interface parameters of the triggered vehicle infotainment functions can be the type of the preset interface of the triggered vehicle infotainment functions and the vehicle infotainment function identifier, but are not limited to this.

[0153] The inconsistency between the aforementioned interface scheduling parameters and the preset interface parameters of the triggered vehicle-mounted function may refer to the following: the type of the service interface called by the application layer is inconsistent with the type of the preset interface of the triggered vehicle-mounted function, and / or the vehicle-mounted function identifier of the service interface called by the application layer is inconsistent with the vehicle-mounted function identifier of the preset interface of the triggered vehicle-mounted function.

[0154] In some implementations, determining the abnormal function and variable value in the vehicle system based on the execution stack of each scheduling link may include:

[0155] Identify scheduling links with anomalies as abnormal links;

[0156] Pop the first sub-stack in the execution stack of the abnormal link to obtain multiple function calls of the abnormal link;

[0157] Based on multiple preset functions of the abnormal link, at least one function function that is abnormal is identified among the multiple function functions of the abnormal link.

[0158] In this embodiment, firstly, the anomaly detection steps described above identify the scheduling links exhibiting anomalies as abnormal links. Then, for each abnormal link, the execution stack of the abnormal link is obtained, and the first sub-stack within the execution stack is popped to obtain multiple function calls for the abnormal link. Next, based on the multiple preset function calls for the abnormal link, at least one function call exhibiting anomaly is identified from among these functions. Thus, by utilizing the function calls stored in the first sub-stack, the abnormal function calls in the vehicle infotainment system can be quickly and accurately located, thereby improving the efficiency and accuracy of fault location in the vehicle infotainment system.

[0159] The aforementioned abnormal function refers to the function that causes abnormalities in the vehicle infotainment system, and can be understood as an abnormal function.

[0160] The method for determining the abnormal function can be set according to the actual situation, and this implementation method does not impose specific limitations on it.

[0161] For example, in some embodiments, determining at least one abnormal function among multiple function functions of an abnormal link based on multiple preset functions of the abnormal link may include comparing function functions located at the same arrangement position with preset functions based on the arrangement position of each function function and the arrangement position of each preset function; for the first The function, if the first function The pseudocode of the first function is the same as the first... If the pseudocode of the first preset function is different, then the first... The first function is determined to be a function with an anomaly; otherwise, the second function is determined to be a function with an anomaly. All functional functions are normal; by traversing the functional functions of the abnormal link, at least one functional function with an abnormality is found.

[0162] For example, in some embodiments, determining at least one abnormal function among multiple function functions of an abnormal link based on multiple preset functions of the abnormal link may include comparing function functions located at the same arrangement position with preset functions based on the arrangement position of each function function and the arrangement position of each preset function; for the first The function, if the first function The vehicle infotainment system functions of the first function and the second function If the vehicle's infotainment system functions differently for each preset function, then the first preset function will be used. The first function is determined to be a function with an anomaly; otherwise, the second function is determined to be a function with an anomaly. All functional functions are normal; by traversing the functional functions of the abnormal link, at least one functional function with an abnormality is found.

[0163] For example, in some embodiments, determining at least one abnormal function among multiple function functions of an abnormal link based on multiple preset functions of the abnormal link may include comparing function functions located at the same arrangement position with preset functions based on the arrangement position of each function function and the arrangement position of each preset function; for the first The function, if the first function The vehicle infotainment system functions of the first function and the second function The vehicle infotainment system functions differ for each preset function and / or the first... The pseudocode of the first function is the same as the first... If the pseudocode of the first preset function is different, then the first... The first function is determined to be a function with an anomaly; otherwise, the second function is determined to be a function with an anomaly. All functional functions are normal; by traversing the functional functions of the abnormal link, at least one functional function with an abnormality is found.

[0164] It is understandable that when there are at least two abnormal links, this implementation method is executed sequentially or simultaneously on each abnormal link.

[0165] In some implementations, the determination of abnormal function functions and abnormal variable values ​​in the vehicle system based on the execution stack of each scheduling link may further include:

[0166] Pop the second sub-stack in the execution stack of the exception chain to obtain multiple variable values ​​of the exception chain;

[0167] For each abnormal function in the abnormal link, based on the mapping set of the abnormal function, at least one variable value corresponding to the abnormal function is determined as a candidate variable value from among the multiple variable values ​​of the abnormal link. Based on the multiple preset variable values ​​of the abnormal function, at least one abnormal variable value is determined from among the multiple candidate variable values.

[0168] In this embodiment, the abnormality of the function is often caused by the incorrect application of the variable value of the function. Therefore, after identifying the abnormal function, the abnormal function can be used in combination with the second sub-stack to determine the abnormal variable value in the vehicle system. Specifically, for ease of understanding, the position of the function with an anomaly in the first sub-stack is defined as the pointer position, and the position of the variable value in the second sub-stack is defined as the candidate position. The function popped from the first sub-stack carries a corresponding mapping set. According to the mapping set, the pointer position and some candidate positions are strongly correlated. Therefore, for a single anomaly chain, the second sub-stack in the execution stack of the anomaly chain is popped first to obtain multiple variable values ​​of the anomaly chain. Then, for each function with an anomaly in the anomaly chain, the candidate position corresponding to the pointer position is determined as the target position among the multiple variable values ​​of the anomaly chain, and the variable value located at the target position is determined as the variable value corresponding to the function with an anomaly, i.e., the candidate variable value. In this way, through the mapping relationship between the function and the variable value, the variable values ​​of the function with an anomaly can be quickly and accurately traversed to obtain. Then, through the multiple preset variable values ​​of the function with an anomaly, at least one variable value with an anomaly is determined from the multiple candidate variable values. By traversing all the abnormal functions in the abnormal link, at least one abnormal variable value in the vehicle system can be found. This allows for faster and more accurate location of abnormal variable values ​​in the vehicle system, thereby improving the efficiency and accuracy of fault location.

[0169] The method for determining abnormal variable values ​​can be set according to the actual situation, and this implementation method does not impose specific limitations on it.

[0170] For example, in some embodiments, the above-mentioned determination of at least one abnormal variable value among multiple candidate variable values ​​based on multiple preset variable values ​​of the abnormal function may include, for each candidate variable value, if the data type of the candidate variable value is different from the numerical type of the preset variable value corresponding to the candidate variable value, then the candidate variable value is determined as the abnormal variable value.

[0171] The data types mentioned above can be set according to actual conditions, and this implementation method does not impose specific limitations on them. For example, the data types mentioned above may include numeric types, string types, boolean types, etc., but are not limited to these.

[0172] For example, in some embodiments, the above-mentioned determination of at least one abnormal variable value among multiple candidate variable values ​​based on multiple preset variable values ​​of the abnormal function may include, for each candidate variable value, if the value of the candidate variable value is different from the value of the preset variable value corresponding to the candidate variable value, then the candidate variable value is determined as the abnormal variable value.

[0173] For example, in some embodiments, the above-mentioned determination of at least one abnormal variable value among multiple candidate variable values ​​based on multiple preset variable values ​​of the abnormal function may include, for each candidate variable value, if the data type of the candidate variable value is different from the numerical type of the preset variable value corresponding to the candidate variable value, or if the data type of the candidate variable value is the same as the numerical type of the preset variable value corresponding to the candidate variable value, but the numerical value of the candidate variable value is different from the numerical value of the preset variable value corresponding to the candidate variable value, then the candidate variable value is determined to be an abnormal variable value.

[0174] It is understandable that when there are at least two abnormal links, this implementation method is executed sequentially or simultaneously on each abnormal link.

[0175] To facilitate understanding of the above-described vehicle infotainment system fault location method of this application, an example of a practical application scenario of the above-described vehicle infotainment system fault location method of this application is provided here.

[0176] Reference Figure 2This example of an in-vehicle infotainment system includes a first link, a second link, a third link, and a fourth link. Specifically, the first link is from the framework layer to the system layer. The framework layer transmits the bus signals of each service class to the system layer through the first link, allowing the system layer to receive the bus signals of each service class and complete the interface encapsulation operation. The second link is from the system layer to the framework layer. The system layer transmits the encapsulated service interfaces to the framework layer through the second link, allowing the framework layer to receive the service interfaces of each service class. The third link is from the framework layer to the application layer. The framework layer provides the service interfaces of each service class to the application layer through the third link. The fourth link is from the application layer to the framework layer. In the fourth link, the application layer calls the service class corresponding to the triggered in-vehicle infotainment function in the framework layer through the service interface of the service class corresponding to the triggered in-vehicle infotainment function. Then, the framework layer executes the service class corresponding to the triggered in-vehicle infotainment function, thereby realizing the triggered in-vehicle infotainment function.

[0177] Based on this, the specific steps S201-S204 for implementing the fault location process of the vehicle infotainment system in this example are as follows.

[0178] S201, load the vehicle infotainment software program into the vehicle infotainment system, and conduct real-vehicle testing on the vehicle infotainment system with the loaded software program.

[0179] S202, during the actual vehicle test, acquires multiple function and variable values ​​of each scheduling link and pushes them onto the stack.

[0180] Specifically, for each scheduling link, we have:

[0181] First, based on the scheduling time values ​​of the function calls, multiple function calls in the scheduling chain are pushed sequentially onto the first sub-stack of the scheduling chain. The pushing order of the function calls is positively correlated with the scheduling time value; that is, the earlier the scheduling time value of a function call is, the earlier its pushing order in the first sub-stack. Second, based on the triggering time values ​​of the variable values, multiple variable values ​​in the scheduling chain are pushed sequentially onto the second sub-stack of the scheduling chain. The pushing order of the variable values ​​is positively correlated with the triggering time value; that is, the earlier the triggering time value of a variable value is, the earlier its pushing order in the second sub-stack.

[0182] Then, for each function in the first substack, based on the substack mapping data, at least one variable value corresponding to the function is determined in the second substack as the target variable value of the function. Based on the arrangement position of the function in the first substack and the arrangement position of each target variable value in the second substack, the mapping identifiers of the function relative to each target variable value are determined as the mapping set of the function. Each mapping identifier can reflect the relationship between the function and each variable value. By traversing each function in the first substack, the mapping set of each function in the first substack can be obtained.

[0183] Finally, the first sub-stack is modified using the mapping set of each function. That is, the mapping set of each function is assigned to each function so that each function carries the corresponding mapping set when popping from the stack, thus obtaining the modified first sub-stack. Based on the second sub-stack and the modified first sub-stack, the execution stack of the scheduling link is constructed.

[0184] S203, after the completion of the real vehicle test, performs anomaly detection on the vehicle infotainment system. The purpose is to detect whether there are any anomalies in the vehicle infotainment system during the real vehicle test, and then obtain the anomaly detection results to realize the anomaly detection of the vehicle infotainment system.

[0185] Specifically, firstly, the vehicle system's real-vehicle test log data is captured using a pre-set log management tool. Based on this data, link parameters are extracted. These parameters include first interface parameters, second interface parameters, third interface parameters, interface scheduling parameters, service execution status, packet loss rate of the first link, packet loss rate of the second link, and packet loss rate of the third link. The first interface parameters are the parameters of the service interfaces encapsulated at the system layer, the second interface parameters are the parameters of the service interfaces received at the framework layer, the third interface parameters are the parameters of the service interfaces received at the application layer, the interface scheduling parameters are the parameters of the service interfaces called by the application layer, and the service execution status includes either a success status or a failure status.

[0186] Then, based on the packet loss rate of the first link, anomaly detection is performed on the first link. More specifically, if the packet loss rate of the first link is greater than a preset first packet loss threshold, it is determined that the first link has an anomaly; otherwise, it is determined that the first link does not have an anomaly.

[0187] Simultaneously, anomaly detection is performed on the second link based on the first interface parameters, the second interface parameters, and the packet loss rate of the second link. More specifically, if at least one of the following conditions is met: the first interface parameters are inconsistent with the preset encapsulation interface parameters, the first interface parameters are inconsistent with the second interface parameters, or the packet loss rate of the second link is greater than the preset second packet loss threshold, then it is determined that the second link is abnormal; otherwise, it is determined that the second link is not abnormal.

[0188] Simultaneously, based on the second interface parameters, the third interface parameters, and the packet loss rate of the third link, anomaly detection is performed on the third link. More specifically, if the second interface parameters and the third interface parameters are inconsistent, and / or the packet loss rate of the third link is greater than a preset third packet loss threshold, then it is determined that the third link is abnormal; otherwise, it is determined that the third link is not abnormal.

[0189] Simultaneously, anomaly detection is performed on the fourth link based on the interface scheduling parameters and the service class execution status. More specifically, if the interface scheduling parameters are inconsistent with the preset interface parameters of the triggered vehicle system function, and / or the service class execution status is in a failed state, then it is determined that there is an anomaly in the fourth link; otherwise, it is determined that there is no anomaly in the fourth link.

[0190] If at least one scheduling link is detected as abnormal through the above anomaly detection, the anomaly detection result is determined to be that there is an anomaly in the vehicle system during the actual vehicle test.

[0191] S204. After completing the anomaly detection, if the anomaly detection result indicates that the vehicle infotainment system was faulty during the actual vehicle test, then the problem in the vehicle infotainment system needs to be located and addressed. The location and addressing process consists of two stages: the first stage is to locate the function that is faulty, and the second stage is to locate the variable value that is faulty.

[0192] Specifically, in the first stage, firstly, the scheduling links with anomalies are identified as abnormal links; then, for a single abnormal link, the first sub-stack in the execution stack of the abnormal link is popped to obtain multiple function functions of the abnormal link, and the function functions located in the same position are compared with the preset functions according to the arrangement position of each function function and the arrangement position of each preset function; for the first... The function, if the first function The vehicle infotainment system functions of the first function and the second function The vehicle infotainment system functions differ for each preset function and / or the first... The pseudocode of the first function is the same as the first... If the pseudocode of the first preset function is different, then the first... The first function is determined to be a function with an anomaly; otherwise, the second function is determined to be a function with an anomaly. All functional functions are normal. Thus, by traversing the functional functions of the abnormal link, at least one functional function in the vehicle system that is abnormal can be found.

[0193] In the second stage, the anomalies of the function are often caused by the incorrect application of variable values ​​in the function. Therefore, after identifying the function with anomalies, the function with anomalies can be used in conjunction with the second sub-stack to determine the variable values ​​with anomalies in the vehicle system.

[0194] More specifically, the position of the function with an anomaly in the first sub-stack is defined as the pointer position, and the position of the variable value in the second sub-stack is defined as the candidate position. The function popped from the first sub-stack carries a corresponding mapping set. According to the mapping set, the pointer position and some candidate positions are strongly correlated. Therefore, for a single anomaly chain, the second sub-stack in the execution stack of the anomaly chain is popped first to obtain multiple variable values ​​of the anomaly chain. Then, for each function with an anomaly in the anomaly chain, the candidate position corresponding to the pointer position is determined as the target position among the multiple variable values ​​of the anomaly chain, and the variable value located at the target position is determined as the variable value corresponding to the function with an anomaly, i.e., the candidate variable value. In this way, through the mapping relationship between the function and the variable value, the variable values ​​of the function with an anomaly can be quickly and accurately traversed to obtain. Then, through the multiple preset variable values ​​of the function with an anomaly, at least one variable value with an anomaly is determined from the multiple candidate variable values. By traversing all the abnormal functions in the abnormal link, at least one abnormal variable value in the vehicle system can be found. This allows for faster and more accurate location of abnormal variable values ​​in the vehicle system, thereby improving the efficiency and accuracy of fault location.

[0195] Secondly, the implementation method of the vehicle system fault location device provided in this application is described in conjunction with the accompanying drawings. (Refer to...) Figure 5 The vehicle infotainment system fault location device provided in this application embodiment may include:

[0196] The first processing module 301 is used to perform real-vehicle testing on the vehicle's infotainment system and obtain the execution stacks of each scheduling link of the infotainment system. The different scheduling links are links connecting different architecture layers of the infotainment system, and the execution stacks of the scheduling links are used to store multiple function calls and multiple variable values ​​of the scheduling links during the real-vehicle testing.

[0197] The second processing module 302 is used to perform anomaly detection on the vehicle infotainment system and obtain anomaly detection results. The anomaly detection results are used to characterize whether there are any anomalies in the vehicle infotainment system during real vehicle testing.

[0198] The third processing module 303 is used to determine the abnormal function and abnormal variable value in the vehicle system based on the execution stack of each scheduling link if the anomaly detection result indicates that there is an anomaly in the vehicle system during the actual vehicle test.

[0199] The content of the above method embodiments is applicable to the device embodiments. The specific functions implemented by the device embodiments are the same as those of the above method embodiments, and the beneficial effects achieved are also the same as those achieved by the above method embodiments.

[0200] Finally, refer to Figure 6 This application also provides a vehicle, which may include:

[0201] At least one processor 401;

[0202] At least one memory 402 is used to store at least one program;

[0203] When at least one program is executed by at least one processor 401, the at least one processor 401 implements the above-described vehicle system fault location method.

[0204] The aforementioned vehicles can be private cars, such as sedans, sport utility vehicles (SUVs), multi-purpose vehicles (MPVs), or pickup trucks, or commercial vehicles, such as vans, buses, small trucks, or large trailers, or gasoline vehicles or new energy vehicles such as hybrid or pure electric vehicles.

[0205] The aforementioned memory 402, as a non-transitory network system, can be used to store non-transitory software programs and non-transitory computer-executable programs. Furthermore, memory 402 may include high-speed random access memory, and may also include non-transitory memory, such as at least one disk storage device, flash memory device, or other non-transitory solid-state storage device. In some embodiments, memory 402 may optionally include memory 402 remotely located relative to processor 401, and these remote memories 402 can be connected to processor 401 via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0206] The aforementioned memory 402 can be implemented as a read-only memory (ROM), static storage device, dynamic storage device, or random access memory (RAM). Memory 402 can store the operating system and other applications. When the technical solutions provided in the embodiments of this specification are implemented through software or firmware, the relevant program code is stored in memory 402 and called by processor 401 to execute the methods of the embodiments of this application.

[0207] The processor 401 described above can be implemented using a general-purpose central processing unit (CPU), microprocessor, application-specific integrated circuit (ASIC), or one or more integrated circuits, and is used to execute relevant programs to implement the technical solutions provided in the embodiments of this application.

[0208] In some embodiments, the vehicle may further include:

[0209] Input / output interfaces are used to implement information input and output;

[0210] The communication interface is used to enable communication and interaction between this device and other devices. Communication can be achieved through wired means (such as USB, Ethernet cable, etc.) or wireless means (such as mobile network, WIFI, Bluetooth, etc.).

[0211] The bus transmits information between various components of the device (such as processor 401, memory 402, input / output interface and communication interface);

[0212] The processor 401, memory 402, input / output interface, and communication interface can communicate with each other within the device via a bus.

[0213] The content of the above method embodiments is applicable to this vehicle embodiment. The specific functions implemented in this vehicle embodiment are the same as those in the above method embodiments, and the beneficial effects achieved are also the same as those achieved in the above method embodiments.

[0214] In some alternative embodiments, the functions / operations mentioned in the block diagrams may not occur in the order shown in the operation diagrams. For example, depending on the functions / operations involved, two consecutively shown blocks may actually be executed substantially simultaneously, or the blocks may sometimes be executed in reverse order. Furthermore, the embodiments presented and described in the flowcharts of this application are provided by way of example to provide a more comprehensive understanding of the technology. The disclosed methods are not limited to the operations and logic flows presented herein. Alternative embodiments are contemplated in which the order of various operations is changed and sub-operations described as part of a larger operation are executed independently.

[0215] Furthermore, although this application is described in the context of functional modules, it should be understood that, unless otherwise stated to the contrary, one or more of the functions and / or features may be integrated into a single physical device and / or software module, or one or more functions and / or features may be implemented in a separate physical device or software module. It is also understood that a detailed discussion of the actual implementation of each module is unnecessary for understanding this application. Rather, given the properties, functions, and internal relationships of the various functional modules in the apparatus disclosed herein, the actual implementation of the module will be understood within the scope of conventional technology for an engineer. Therefore, those skilled in the art can implement the application set forth in the claims using ordinary techniques without excessive experimentation. It is also understood that the specific concepts disclosed are merely illustrative and not intended to limit the scope of this application, which is determined by the full scope of the appended claims and their equivalents.

[0216] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several programs to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0217] The logic and / or steps represented in the flowchart or otherwise described herein, for example, can be considered as a sequential list of executable programs for implementing logical functions, and can be embodied in any computer-readable medium for use by, or in conjunction with, a program execution system, apparatus, or device (such as a computer-based system, a processor-included system, or other system that can retrieve and execute a program from or in conjunction with such a program execution system, apparatus, or device). For the purposes of this specification, "computer-readable medium" can mean any means that can contain, store, communicate, propagate, or transmit a program for use by or in conjunction with a program execution system, apparatus, or device.

[0218] More specific examples of computer-readable media (a non-exhaustive list) include: electrical connections (electronic devices) having one or more wires, portable computer disk drives (magnetic devices), random access memory (RAM), read-only memory (ROM), erasable and editable read-only memory (EPROM or flash memory), fiber optic devices, and portable optical disc read-only memory (CDROM). Furthermore, computer-readable media can even be paper or other suitable media on which the program can be printed, because the program can be obtained electronically, for example, by optically scanning the paper or other medium, followed by editing, interpreting, or otherwise processing as necessary, and then stored in computer memory.

[0219] It should be understood that various parts of this application can be implemented using hardware, software, firmware, or a combination thereof. In the above embodiments, multiple steps or methods can be implemented using software or firmware stored in memory and executed by a suitable program execution system. For example, if implemented in hardware, as in another embodiment, it can be implemented using any one or a combination of the following techniques known in the art: discrete logic circuits having logic gates for implementing logical functions on data signals, application-specific integrated circuits (ASICs) having suitable combinational logic gates, programmable gate arrays (PGAs), field-programmable gate arrays (FPGAs), etc.

[0220] In the foregoing description of this specification, the references to terms such as "one embodiment," "another embodiment," or "some embodiments," etc., indicate that a specific feature, structure, material, or characteristic described in connection with an embodiment or example is included in at least one embodiment or example of this application. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples.

[0221] Although embodiments of this application have been shown and described, those skilled in the art will understand that various changes, modifications, substitutions and variations can be made to these embodiments without departing from the principles and spirit of this application, the scope of which is defined by the claims and their equivalents.

[0222] The above is a detailed description of the preferred embodiments of this application, but this application is not limited to the embodiments described. Those skilled in the art can make various equivalent modifications or substitutions without departing from the spirit of this application, and these equivalent modifications or substitutions are all included within the scope defined by the claims of this application.

Claims

1. A method for locating faults in a vehicle infotainment system, characterized in that, Includes the following steps: A real-vehicle test is conducted on the vehicle's infotainment system to obtain the execution stacks of each scheduling link of the infotainment system; wherein, different scheduling links are links connecting different architecture layers of the infotainment system, and the execution stacks of the scheduling links are used to store multiple function calls and multiple variable values ​​of the scheduling links during the real-vehicle test; Anomaly detection is performed on the vehicle infotainment system to obtain anomaly detection results, which are used to characterize whether there are any anomalies in the vehicle infotainment system during real vehicle testing. If the anomaly detection result indicates that the vehicle system is abnormal during the actual vehicle test, then the abnormal function and abnormal variable value in the vehicle system are determined according to the execution stack of each scheduling link. The step of performing anomaly detection on the vehicle infotainment system and obtaining anomaly detection results includes: Obtain the real-vehicle test log data of the in-vehicle infotainment system; Based on the actual vehicle test log data, anomaly detection is performed on each of the scheduling links; If at least one of the scheduling links is detected to be abnormal, then the abnormality detection result is determined to be that the vehicle system is abnormal during the actual vehicle test; The vehicle system contains at least one of the following scheduling links: The first link is used to characterize the link from the framework layer of the vehicle system to the system layer of the vehicle system; The second link is used to characterize the link from the system layer to the framework layer; The third link is used to characterize the link from the framework layer to the application layer of the vehicle system; The fourth link is used to characterize the link from the application layer to the framework layer; The step of performing anomaly detection on each of the scheduling links based on the actual vehicle test log data includes: Based on the actual vehicle test log data, the link parameters are obtained; The link parameters include a first interface parameter, a second interface parameter, a third interface parameter, an interface scheduling parameter, a service class execution status, a packet loss rate of the first link, a packet loss rate of the second link, and a packet loss rate of the third link. The first interface parameter is the parameter of the service interface encapsulated by the system layer, the second interface parameter is the parameter of the service interface received by the framework layer, the third interface parameter is the parameter of the service interface received by the application layer, the interface scheduling parameter is the parameter of the service interface called by the application layer, and the service class execution status includes either a success status or a failure status. The step of performing anomaly detection on each of the scheduling links based on the actual vehicle test log data further includes at least one of the following: Based on the packet loss rate of the first link, perform anomaly detection on the first link; Based on the first interface parameters, the second interface parameters, and the packet loss rate of the second link, anomaly detection is performed on the second link; Based on the second interface parameters, the third interface parameters, and the packet loss rate of the third link, anomaly detection is performed on the third link; Based on the interface scheduling parameters and the service class execution status, anomaly detection is performed on the fourth link.

2. The vehicle infotainment system fault location method according to claim 1, characterized in that, The actual vehicle testing of the vehicle's infotainment system yields the execution stacks of each scheduling link of the system, including: Load the preset vehicle infotainment software program into the vehicle infotainment system; A real-vehicle test was conducted on the in-vehicle infotainment system loaded with the aforementioned in-vehicle software program; For each scheduling link in the vehicle system, the execution stack of the scheduling link is obtained based on multiple function and variable values ​​of the scheduling link during the actual vehicle test.

3. The vehicle infotainment system fault location method according to claim 2, characterized in that, The step of obtaining the execution stack of the scheduling link based on multiple function calls and multiple variable values ​​during real vehicle testing includes: Push multiple function calls of the scheduling link onto the first sub-stack of the scheduling link; Push the multiple variable values ​​of the scheduling link into the second sub-stack of the scheduling link; The execution stack of the scheduling link is obtained based on the first sub-stack and the second sub-stack.

4. The vehicle infotainment system fault location method according to claim 3, characterized in that, The step of obtaining the execution stack of the scheduling link based on the first sub-stack and the second sub-stack includes: For each function in the first sub-stack, based on the sub-stack mapping data, at least one variable value corresponding to the function in the second sub-stack is determined as the target variable value of the function. Based on the arrangement position of the function in the first sub-stack and the arrangement position of each target variable value in the second sub-stack, the mapping identifier of the function relative to each target variable value is obtained as an element of the mapping set of the function; wherein, the sub-stack mapping data includes multiple preset function functions and at least one variable value corresponding to each preset function; The first substack is modified by using the mapping set of each function of the first substack to obtain the modified first substack; The execution stack of the scheduling link is constructed based on the second sub-stack and the modified first sub-stack.

5. The vehicle infotainment system fault location method according to claim 1, characterized in that, The step of determining the abnormal function and abnormal variable value in the vehicle system based on the execution stack of each scheduling link includes: Identify scheduling links with anomalies as abnormal links; Pop the first sub-stack in the execution stack of the abnormal link to obtain multiple function calls of the abnormal link; Based on the multiple preset functions of the abnormal link, at least one of the abnormal function functions is determined from the multiple function functions of the abnormal link.

6. The vehicle infotainment system fault location method according to claim 5, characterized in that, The step of determining the abnormal function and abnormal variable value in the vehicle system based on the execution stack of each scheduling link further includes: Pop the second sub-stack in the execution stack of the abnormal link to obtain multiple variable values ​​of the abnormal link; For each of the abnormal function functions in the abnormal link, based on the mapping set of the abnormal function functions, at least one variable value corresponding to the abnormal function is determined as a candidate variable value from among the multiple variable values ​​of the abnormal link, and based on the multiple preset variable values ​​of the abnormal function functions, at least one abnormal variable value is determined from among the multiple candidate variable values.

7. The vehicle infotainment system fault location method according to any one of claims 1-6, characterized in that, The framework layer is configured with multiple service classes, each corresponding to at least one vehicle function of the vehicle system; the system layer is used to encapsulate the bus signals of each service class into corresponding service interfaces and return them to the framework layer; the framework layer is used to provide the service interfaces of each service class to the application layer. The application layer is used to call the service class corresponding to the triggered vehicle infotainment function through the service interface of the service class corresponding to the triggered vehicle infotainment function when the vehicle infotainment function of the vehicle infotainment system is triggered; the framework layer is used to execute the service class corresponding to the triggered vehicle infotainment function.

8. A vehicle infotainment system fault location device, characterized in that, include: The first processing module is used to perform real-vehicle testing on the vehicle's infotainment system and obtain the execution stacks of each scheduling link of the infotainment system; wherein, the different scheduling links are links connecting different architecture layers of the infotainment system, and the execution stacks of the scheduling links are used to store multiple function calls and multiple variable values ​​of the scheduling links during the real-vehicle testing. The second processing module is used to perform anomaly detection on the vehicle infotainment system and obtain anomaly detection results. The anomaly detection results are used to characterize whether there are any anomalies in the vehicle infotainment system during real vehicle testing. The third processing module is used to determine the abnormal function and abnormal variable value in the vehicle system according to the execution stack of each scheduling link if the anomaly detection result indicates that the vehicle system has an anomaly during the actual vehicle test. The step of performing anomaly detection on the vehicle infotainment system and obtaining anomaly detection results includes: Obtain the real-vehicle test log data of the in-vehicle infotainment system; Based on the actual vehicle test log data, anomaly detection is performed on each of the scheduling links; If at least one of the scheduling links is detected to be abnormal, then the abnormality detection result is determined to be that the vehicle system is abnormal during the actual vehicle test; The vehicle system contains at least one of the following scheduling links: The first link is used to characterize the link from the framework layer of the vehicle system to the system layer of the vehicle system; The second link is used to characterize the link from the system layer to the framework layer; The third link is used to characterize the link from the framework layer to the application layer of the vehicle system; The fourth link is used to characterize the link from the application layer to the framework layer; The step of performing anomaly detection on each of the scheduling links based on the actual vehicle test log data includes: Based on the actual vehicle test log data, the link parameters are obtained; The link parameters include a first interface parameter, a second interface parameter, a third interface parameter, an interface scheduling parameter, a service class execution status, a packet loss rate of the first link, a packet loss rate of the second link, and a packet loss rate of the third link. The first interface parameter is the parameter of the service interface encapsulated by the system layer, the second interface parameter is the parameter of the service interface received by the framework layer, the third interface parameter is the parameter of the service interface received by the application layer, the interface scheduling parameter is the parameter of the service interface called by the application layer, and the service class execution status includes either a success status or a failure status. The step of performing anomaly detection on each of the scheduling links based on the actual vehicle test log data further includes at least one of the following: Based on the packet loss rate of the first link, perform anomaly detection on the first link; Based on the first interface parameters, the second interface parameters, and the packet loss rate of the second link, anomaly detection is performed on the second link; Based on the second interface parameters, the third interface parameters, and the packet loss rate of the third link, anomaly detection is performed on the third link; Based on the interface scheduling parameters and the service class execution status, anomaly detection is performed on the fourth link.

9. A vehicle, characterized in that, include: At least one processor; At least one memory for storing at least one program; When the at least one program is executed by the at least one processor, the at least one processor implements the vehicle system fault location method as described in any one of claims 1-7.

Images