A remote test restart method of a vehicle head unit, an electronic device, and a storage medium

Abstract

The application provides a remote test restart method of a vehicle machine, an electronic device and a storage medium, relates to the technical field of remote test restart of a vehicle machine, and the method comprises the following steps: acquiring a time sequence waveform of each type of running data of a target machine in a preset historical time period to obtain a time sequence waveform list A; acquiring a historical time sequence waveform list corresponding to the i-th type of running data; obtaining a running data feature word list B corresponding to A; inputting B into a preset first N-Gram model for predicting a target machine restart instruction to generate a restart label corresponding to the target machine; if the restart label corresponds to a restart instruction, sending the restart instruction corresponding to the restart label to the target machine to control the target machine to perform a restart operation; otherwise, not sending the restart instruction to the target machine; the application avoids omission of key state testing and reduces repeated testing of non-key states, thereby comprehensively improving the completeness and pertinence of test coverage.

Description

Technical Field

[0001] This invention relates to the field of remote test and restart technology for vehicle infotainment systems, and in particular to a remote test and restart method, electronic device, and storage medium for vehicle infotainment systems. Background Technology

[0002] With the rapid development of intelligent connected vehicle technology, the functions of vehicle infotainment systems are becoming increasingly complex, making their stability and reliability testing a crucial aspect of ensuring safe vehicle operation. Restarting is an important testing method during infotainment system testing, verifying key indicators such as the system's recovery capabilities under different states, data storage and loading performance, and system stability. Currently, triggering restarts during infotainment system testing primarily relies on proactive intervention from personnel. Testers typically preset restart times based on experience or manually trigger restart commands upon observing specific phenomena. While this approach can be effective in some deterministic testing scenarios, its limitations become increasingly apparent in complex testing environments, especially during fuzzy testing.

[0003] Fuzz testing, as a testing method that discovers potential vulnerabilities in a system by inputting unexpected data, needs to cover as many operating states and boundary conditions as possible for the vehicle's infotainment system. However, in existing technologies, restart operations during fuzz testing can generally only be implemented through random triggering. This random triggering method lacks targeted analysis of the actual operating state of the vehicle's infotainment system, easily leading to incomplete test coverage. Restart tests in some critical operating states may be missed, while some non-critical states are repeatedly tested. At the same time, the random triggering method cannot dynamically adjust the restart strategy based on the real-time operating data of the vehicle's infotainment system, resulting in low testing efficiency and making it difficult to meet the comprehensive testing needs of complex vehicle infotainment systems. Therefore, how to achieve intelligent and precise triggering of restart operations in remote testing of vehicle infotainment systems to solve the problems of incomplete test coverage and low efficiency in existing methods has become an urgent technical challenge to be solved in this field. Summary of the Invention

[0004] To address the aforementioned technical problems, the technical solution adopted by this invention is as follows:

[0005] According to a first aspect of this application, a remote test restart method for a vehicle's infotainment system is provided, the method comprising the following steps:

[0006] S100, acquire the time-series waveforms of each type of operational data of the target vehicle's infotainment system within a preset historical time period T, to obtain a time-series waveform list A = (A1, A2, ..., A...). i A n ), i=1,2,…,n; A iLet n be the timing waveform corresponding to the i-th type of running data, and n be the number of running data types of the target vehicle system.

[0007] S200, Obtain the historical time-series waveform list L corresponding to the i-th type of runtime data. i =(L i，1 L i，2 , ..., L i，j , ..., L i，f（i） ), L i，j Let f(i) be the j-th historical time series waveform corresponding to the i-th type of running data, and f(i) be the number of historical time series waveforms corresponding to the i-th type of running data; each historical time series waveform corresponds to a standard running data feature word;

[0008] S300, according to A i With L i The similarity between each historical time-series waveform is used to determine A. i Corresponding runtime data feature word B i This leads to the list of runtime data feature words corresponding to A, B = (B1, B2, ..., B...). i B n );

[0009] S400: Input B into the preset first N-Gram model for predicting the target vehicle's restart command, and generate the restart label corresponding to the target vehicle.

[0010] S500, if the restart tag corresponds to a restart instruction, then the restart instruction corresponding to the restart tag is sent to the target vehicle unit to control the target vehicle unit to execute the restart operation corresponding to the restart instruction; otherwise, no restart instruction is sent to the target vehicle unit.

[0011] According to another aspect of this application, a non-transitory computer-readable storage medium is also provided, wherein at least one instruction or at least one program is stored in the storage medium, and the at least one instruction or at least one program is loaded and executed by a processor to implement the above-described method for remotely opening vehicle components.

[0012] According to another aspect of this application, an electronic device is also provided, including a processor and the aforementioned non-transitory computer-readable storage medium.

[0013] The present invention has at least the following beneficial effects:

[0014] The remote test restart method for vehicle infotainment systems of this invention acquires the time-series waveforms of various operating data of the target infotainment system within a preset historical time period, matches corresponding operating data feature words with a list of historical time-series waveforms, and then generates a restart command using a preset N-Gram model. This transforms the restart operation from manual intervention or random triggering to intelligent and precise triggering. Specifically, compared to the existing technology that relies on staff to actively set time nodes, this method can dynamically determine the restart timing based on real-time operating data of the infotainment system without manual intervention, significantly reducing labor costs and avoiding test deviations caused by differences in human experience. Addressing the limitations of random restart triggering in fuzzy testing, this method generates restart commands by analyzing the actual operating state characteristics of the infotainment system. This allows for precise capture of key operating states and targeted restart triggering, avoiding omissions in key state testing and reducing repetitive testing of non-critical states, thereby comprehensively improving the completeness and relevance of test coverage. Simultaneously, this intelligent triggering method based on data features can dynamically adjust the restart strategy according to changes in the operating state of the infotainment system, effectively improving testing efficiency in scenarios such as fuzzy testing, and better adapting to the comprehensive and efficient testing needs of complex infotainment systems. Attached Figure Description

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

[0016] Figure 1 A flowchart of a remote test restart method for a vehicle infotainment system provided in an embodiment of the present invention. Detailed Implementation

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

[0018] It should be noted that, based on this disclosure, those skilled in the art will understand that one aspect described herein can be implemented independently of any other aspect, and two or more of these aspects can be combined in various ways. For example, any number of aspects set forth herein can be used to implement the device and / or practice the method. Furthermore, this device and / or practice the method can be implemented using other structures and / or functionalities besides one or more of the aspects set forth herein.

[0019] The following will refer to Figure 1 The flowchart shown illustrates a method for remotely testing and restarting a vehicle's infotainment system, introducing such a method.

[0020] The remote test restart method for the vehicle's infotainment system may include the following steps:

[0021] S100, acquire the time-series waveforms of each type of operational data of the target vehicle's infotainment system within a preset historical time period T, to obtain a time-series waveform list A = (A1, A2, ..., A...). i A n ), i=1,2,…,n; A i Let be the timing waveform corresponding to the i-th type of running data, and n be the number of running data types of the target vehicle system.

[0022] The method in this embodiment is applied to vehicle infotainment testing scenarios, such as smart cockpit infotainment systems; it collects dynamic change curves of multiple types of operating data within a specific time window under the current testing scenario of the vehicle infotainment system, providing raw data support for subsequent "current state recognition".

[0023] The preset historical time period T can be set according to the fluctuation characteristics of the vehicle's operating data. It needs to take into account both "capturing the complete state" and "real-time performance", and is usually set to 5-20 seconds (example: T=10 seconds, that is, collecting the operating data of "10 seconds before the current moment").

[0024] Running data type n: Covers the core operating dimensions of the vehicle system, determined by testing requirements. Common types include: A1: CPU load (unit: %); A2: Memory usage (unit: %); A3: Core temperature (unit: ℃); A4: Network latency (unit: ms).

[0025] Data acquisition can be performed through the vehicle's OBD interface, CAN bus, or remote communication module (such as 4G / 5G) to collect various types of operational data at a fixed sampling frequency (such as 0.5 seconds / time).

[0026] The original data sequence is plotted as a continuous curve (i.e., time series waveform) along the "time-value" dimension. The waveform should retain the dynamic trend of the data (such as rising, falling, stable, or fluctuating).

[0027] Example: The timing waveform of A1 shows "the first 5 seconds increase from 65% to 82% (upward trend), and the next 5 seconds decrease from 82% to 55% (downward trend)," which intuitively reflects the short-term change pattern of CPU load.

[0028] This step can replace subjective human judgment, eliminating the need for testers to manually record or estimate the vehicle's status. It completely restores the dynamic changes of the operating data through objective time-series waveforms, avoiding errors from human observation (such as missing brief high load peaks).

[0029] The time-series waveform contains detailed information such as "trend, peak value, and fluctuation frequency", which can better reflect the actual operating status of the vehicle system than static data at a single point in time, thus solving the problem that "it is not comprehensive to judge the status by using only static data".

[0030] S200, Obtain the historical time-series waveform list L corresponding to the i-th type of runtime data. i =(L i，1 L i，2 , ..., L i，j , ..., L i，f（i） ), L i，j Let f(i) be the j-th historical time series waveform corresponding to the i-th type of running data, and f(i) be the number of historical time series waveforms corresponding to the i-th type of running data; each historical time series waveform corresponds to a standard running data feature word.

[0031] This step establishes a historical benchmark library for various types of operational data, with each historical waveform associated with "semantic standard feature words," providing a reference for subsequent "similarity matching between current waveforms and historical waveforms."

[0032] It can accumulate various types of runtime data timing waveforms recorded in past vehicle system tests (such as functional tests, stress tests, and fuzz tests), covering all scenarios such as "normal state", "minor anomaly", and "serious anomaly".

[0033] For the i-th type of running data, L i It contains f(i) historical waveforms (f(i) is the amount of historical data; in the example, the CPU load corresponds to f(1) = 200, i.e., L). i =(L i,1 L i,2 , ..., L i,200 )).

[0034] Example: L i,1 (CPU load historical waveform): Data steadily increased from 50% to 55% within 10 seconds (trend: slow increase, peak at 55%); L i,200 (CPU load history waveform): The data jumped from 70% to 95% within 10 seconds (trend: rapid rise, peak 95%).

[0035] Based on the "key features" of historical waveforms (such as peak value, trend, and fluctuation range), assign a unique semantic label (feature word). The label should be concise and able to distinguish the state.

[0036] The preset labeling rules (taking CPU load as an example) are shown in Table 1:

[0037] Table 1

[0038]

[0039] Association method: Each historical waveform L i,j All are bound to a standard feature word (such as L) i,1 Related to "CPU low load stability", L i,200 (Related to "Sudden Surge in CPU Load").

[0040] This step has at least the following beneficial effects:

[0041] Establish a unified state semantic standard: avoid differences in the description of "vehicle system status" by different testers (e.g., some people call "CPU load 80%" "high load", while others call it "medium-high load"), and achieve consistency in state definition through standardized feature words.

[0042] Provides "semantic anchors" for similarity matching: In subsequent steps, "similarity between the current waveform and historical waveforms" can be directly transformed into "correspondence between the current state and standard feature words", which solves the problem that "semantic states cannot be associated by numerical matching alone".

[0043] S300, according to A i With L i The similarity between each historical time-series waveform is used to determine A. i Corresponding runtime data feature word B i This leads to the list of runtime data feature words corresponding to A, B = (B1, B2, ..., B...). i B n ).

[0044] Through "Current Waveform A" i Compared with historical waveform L i "Similarity calculation" matches the unique semantic feature word B to the current running data. i This transforms "numerical waveforms" into "symbolic sequences that can be processed by the N-Gram model".

[0045] Furthermore, step S300 may include the following steps:

[0046] S310, according to L i The eigenvector corresponding to each historical time-series waveform in L i Clustering of historical time-series waveforms in L is performed to obtain L i The corresponding cluster list C = (C1, C2, ..., C...) p C q ), p=1,2,…,q; Cp For L i The p-th cluster is obtained by clustering the historical time-series waveforms in L, where q represents the cluster of L. i The number of clusters obtained by clustering historical time-series waveforms.

[0047] L is a historical time-series waveform list of the i-th type of runtime data (such as memory usage). i In the middle, each waveform L i,j This corresponds to a feature vector (e.g., memory feature vector Y = (average occupancy, peak occupancy, occupancy growth rate, volatility variance)). Assume L... i It contains 200 historical waveforms, which means it has 200 feature vectors.

[0048] The K-means clustering algorithm (unsupervised learning, suitable for quickly clustering similar vectors into one class) is used. After clustering, q clusters are obtained, and each cluster contains several feature vectors (corresponding to similar historical waveforms), i.e., C.

[0049] This step eliminates the need to match the current waveform with all historical waveforms (e.g., 200) one by one. Instead, it only requires calculating the similarity with q cluster centers (e.g., 3), which greatly improves matching efficiency (especially when the amount of historical data is large). Historical waveforms within the same cluster have similar characteristics, and after clustering, a class of states can be represented by the "cluster center," avoiding matching deviations caused by individual differences in a single historical waveform.

[0050] S320, obtain A i The corresponding feature vector XL i The similarity between XL and the center vector corresponding to each cluster in C is used to obtain XL. i The corresponding similarity list η i =(η i，1 η i，2 , ..., η i，p , ..., η i，q ); η i，p For XL i With C p Similarity between them.

[0051] For the current timing waveform A i (For example, memory usage A2) Extract the feature vector, using the same method as the historical waveform. Assuming the 10-second data for A2 is: [75,78,80,82,85,83,86,88,90,92], extract the feature vector: XL i =(Average 83%, Peak 92%, Growth Rate 1.7% / s, Variance 8). XL is calculated using cosine similarity (measures the consistency of vector direction, with a value between 0 and 1). i Similarity with the centers of each cluster.

[0052] By calculating the similarity with the cluster center, the most likely state category to which the current waveform belongs can be quickly determined (e.g., XL in the example). i The highest similarity to C3 indicates that the current memory state is close to the "high memory usage growth" category, providing a clear direction for subsequent feature word matching.

[0053] S330, if η i Maximum similarity η i，max If ≥QR, then η will be randomly selected. i，max The standard runtime data feature word corresponding to a historical time-series waveform in the corresponding cluster is determined to be B. i Otherwise, exit the current processing; QR is the first preset similarity threshold.

[0054] Low-similarity matches are filtered out using QR thresholds (to avoid false positives), while random selection of feature words within the same cluster is allowed (utilizing cluster commonalities to avoid the limitations of a single sample). Combined with the dynamic adjustment of subsequent QRs (correlated with the parameters injected into the test cases), the threshold can be lowered during aggressive testing (tolerating some deviation and increasing matching opportunities), and the threshold can be raised during moderate testing (strict matching to reduce invalid feature words).

[0055] Furthermore, QR can be determined through the following steps:

[0056] S331, obtain the injection strength S and injection risk level R of the current test case of the target vehicle system; S is determined by the amount, frequency and proportion of abnormal data of the input data corresponding to the test case; R is determined by the type of test case; 0≤S≤1; 0≤R≤1.

[0057] In this embodiment, the injection intensity S is calculated (0≤S≤1):

[0058] S reflects the stress of the test case on the vehicle's infotainment system, and is obtained by weighting three quantifiable parameters:

[0059] Input data volume: Current injected test data volume / maximum capacity of vehicle system = 0.8 (e.g., if the maximum capacity of vehicle system is 100 data points / second, the current injection volume is 80 data points / second).

[0060] Input frequency: Current data transmission frequency / maximum allowed frequency = 0.7 (e.g., maximum allowed 50Hz, current 35Hz).

[0061] Abnormal data percentage: Number of abnormal data entries / Total number of data entries = 0.9 (90 out of 100 data entries are in abnormal format).

[0062] If we set weights (data volume 0.3, frequency 0.3, anomaly percentage 0.4), then: S = 0.3 × 0.8 + 0.3 × 0.7 + 0.4 × 0.9 = 0.24 + 0.21 + 0.36 = 0.81.

[0063] Determination of injection risk level R (0≤R≤1):

[0064] R reflects the risk of the test case, based on the preset parameters of the vehicle infotainment module involved in the case:

[0065] Entertainment system test (e.g., abnormal injection during music playback): R=0.2.

[0066] Navigation module test (e.g., location data tampering): R=0.5.

[0067] Security authentication module test (e.g., forged login command): R=0.9.

[0068] Assuming the current test case is "abnormal instruction injection in the security authentication module", then R=0.9.

[0069] This step transforms the abstract concepts of "test pressure" and "risk" into numerical values ​​in the 0-1 range, providing actionable input for subsequent QR calculations. It adapts to multi-scenario testing, with significant differences in S and R between different test cases (such as entertainment module vs. security module), laying the foundation for differentiated QR adjustments.

[0070] S332, Based on S and R, determine the degree of aggression corresponding to the current test case K=α×S+β×R; where α is the injection strength weight and β is the injection risk level weight; α+β=1.

[0071] Weighting: α (injection intensity weight) = 0.5, β (risk level weight) = 0.5 (α + β = 1, indicating equal attention to pressure and risk).

[0072] Calculate K: K = 0.5 × 0.81 + 0.5 × 0.9 = 0.405 + 0.45 = 0.855 (close to 1, indicating that the current test is highly aggressive).

[0073] By weighted fusion of S and R, a single "aggressiveness" metric K is obtained, simplifying the calculation logic of subsequent QR; the focus can be flexibly adjusted, such as increasing α (e.g., α=0.7) if the test focuses more on stress (e.g., load testing), and increasing β (e.g., β=0.7) if the test focuses more on risk (e.g., security testing), to adapt to different test objectives.

[0074] S333, Based on K, determine QR=QR base ×(1-K×γ;where QR base γ is the preset base threshold; γ is the preset adjustment coefficient; 0 < γ < 1.

[0075] Preset parameters: QR base(Basic threshold) = 0.6 (initial value for balancing precision and fault tolerance); γ (adjustment coefficient) = 0.4 (controls the influence of K on QR, 0 < γ < 1).

[0076] Calculate QR: QR=0.6×(1-0.855×0.4)=0.6×(1-0.342)=0.6×0.658≈0.395.

[0077] Furthermore, constraints can be added: if QR < 0.3 (QR min If QR > 0.9 (QR), then take 0.3; max If the threshold is too extreme, then take 0.9 (to avoid the threshold being too extreme).

[0078] Example comparison:

[0079] If the test is flat (S=0.2, R=0.2, K=0.2), then QR=0.6×(1-0.2×0.4)=0.6×0.92≈0.55 (higher threshold, strict match).

[0080] If the test is aggressive (such as K=0.855 above), then QR≈0.4 (lower threshold, looser matching, increased chance of restart).

[0081] Through the above steps, the QR is reduced during aggressive testing (allowing more matches, increasing the restart frequency, and comprehensively testing recovery capabilities); the QR is increased during gradual testing (reducing invalid matches and avoiding frequent restarts from affecting the test process); the formula is simple, requiring only basic arithmetic operations, and can be calculated in real time (millisecond-level response), meeting the real-time requirements of vehicle system testing.

[0082] The above steps have at least the following beneficial effects:

[0083] Efficiency improvement: Clustering transforms "one-to-one" matching into "one-to-cluster" matching, reducing computational load, which is especially suitable for scenarios with large amounts of historical data.

[0084] Matching accuracy: By combining dynamic QR thresholds, we can ensure matching quality while avoiding "missed matches" (aggressive testing) or "false matches" (gradual testing).

[0085] Test adaptability: The injection strength and risk level of QR and test cases are linked, so that the restart trigger logic is deeply matched with the test objectives (such as full coverage vs. precise verification), which solves the limitations of traditional fixed thresholds or random triggers.

[0086] S400 inputs B into the preset first N-Gram model for predicting the target vehicle's restart command, and generates the restart label corresponding to the target vehicle.

[0087] In this embodiment, the pre-setting and training of the first N-Gram model are achieved in the following way:

[0088] Model type: 2-Gram model is adopted. The core logic is to "predict the restart label corresponding to the next feature word based on the previous feature word" (or directly predict the label based on the feature word sequence), which balances computational complexity and prediction accuracy.

[0089] Training data: The mapping data of "feature word list B → actual effective restart command" from historical tests is used. Example training samples are shown in Table 2:

[0090] Table 2

[0091]

[0092] Model training: Calculate the association probability between each "feature word sequence" and "restart label", such as P("soft restart"|"stable CPU high load + high memory usage") = 0.85 (that is, when this sequence appears, there is an 85% probability that a soft restart is required).

[0093] After training the first N-Gram model using the above method, input the current B list obtained in step S300 into the trained N-Gram model. The model determines the restart label by calculating the maximum probability.

[0094] Example: Given B = ("Stable high CPU load", "High memory usage", "Normal temperature", "Low latency"), the model calculates: P("Soft restart"|B) = 0.85, P("Hard restart"|B) = 0.1, P("No restart required"|B) = 0.05; the label with the highest probability is selected to generate the label "Soft restart".

[0095] This step enables intelligent prediction of restart needs, eliminating the need for manual setting of restart time points. The model automatically determines restarts based on historical sequence patterns, solving the problem of low efficiency caused by manual triggering. It avoids misjudgments based on single features by predicting using "multi-type feature word sequences" rather than a single feature (such as only looking at CPU load). For example, a hard restart is not triggered when "CPU load is high but memory and temperature are normal," thus improving the accuracy of restart decisions.

[0096] S500, if the restart tag corresponds to a restart instruction, then the restart instruction corresponding to the restart tag is sent to the target vehicle unit to control the target vehicle unit to execute the restart operation corresponding to the restart instruction; otherwise, no restart instruction is sent to the target vehicle unit.

[0097] Based on the restart label generated by the N-Gram model, it is determined whether to send a restart command to the vehicle system, so as to achieve "precise triggering of restart" or "avoiding invalid restart".

[0098] For example, if the restart label is "soft restart", the soft restart command is encrypted and sent to the target vehicle unit via a remote communication module (such as 4G). After receiving the command, the vehicle unit performs the soft restart operation (which takes about 30 seconds and retains the test data after restarting). If the restart label is "no restart required", no command is sent, and the running data for the next T time period is collected to avoid interrupting the normal test process.

[0099] This step ensures that commands are sent only when the model predicts a restart is required, avoiding the problems of "false restarts in normal states" (wasting test time) or "missed restarts in abnormal states" (missing vulnerabilities) that exist in existing random triggering methods. It is suitable for remote testing scenarios, eliminating the need for on-site operation by testers. Restart control is achieved through remote commands, making it particularly suitable for batch testing of multiple vehicle systems or remote testing scenarios, significantly improving testing efficiency.

[0100] Furthermore, in the above embodiment, steps S100-S500 need to be executed continuously. However, the target vehicle system is not restarted very frequently. Therefore, steps S100-S500 are mostly ineffective. Based on this, before step S100, the method may further include the following steps:

[0101] S010, whenever a new message to be executed is added to the preset first-in-first-out queue, retrieve each message to be executed in the first-in-first-out queue to obtain a list of messages to be executed D = (D1, D2, ..., D...). x D y ), x=1,2,…,y; D x y represents the x-th message to be executed in the first-in-first-out (FIFO) queue, and y represents the length of the FIFO queue.

[0102] During vehicle system testing, remotely sent test commands (such as data query, exception injection, status control, etc.) are stored in a first-in-first-out (FIFO) queue in the order of receipt to ensure that the commands are executed in order (avoiding test logic confusion caused by out-of-order execution).

[0103] The message to be executed is a data packet containing test instructions, including information such as "instruction type," "target module," and "execution time." For example:

[0104] D1: {Type: Query, Target: CPU, Content: Load data, Execution time: 10:00:00};

[0105] D2: {Type: Injection, Target: Navigation, Content: Anomaly Location Data, Execution Time: 10:00:05};

[0106] D3: {Type: Control, Target: Screen, Content: Brightness Adjustment, Execution Time: 10:00:10}.

[0107] Generation of list D: Whenever a new message is added to the queue (such as adding D4), all messages in the queue are read immediately to form D=(D1,D2,D3,D4), where y=4 (queue length).

[0108] By acquiring the pending messages in the queue in real time, the instruction sequence for subsequent tests can be determined, providing context for predicting whether a restart is needed (e.g., a restart is usually required for verification after continuous exception injection).

[0109] S020, perform feature encoding on each message to be executed in D to obtain the message feature vector list E = (E1, E2, ..., E...). x , ..., E y ); E x D x The corresponding message feature vector.

[0110] Feature dimension design: Extract the core attributes of the message as feature dimensions (to ensure that different types of messages can be distinguished), for example:

[0111] Dimension 1: Command type (Query=1, Injection=2, Control=3, Restart=4);

[0112] Dimension 2: Risk level of target modules (Entertainment=0.2, Navigation=0.5, CPU=0.7, Security module=1.0);

[0113] Dimension 3: Data length (short = 0.1, medium = 0.5, long = 0.9);

[0114] Dimension 4: Anomaly marking (normal = 0, minor anomaly = 0.5, severe anomaly = 1.0).

[0115] Feature vector generation: Map the attributes of each message to the above dimensions, and normalize them into vectors ranging from 0 to 1. For example:

[0116] The feature vector of D2 (injected anomalous navigation data) is E2=(2,0.5,0.5,1.0) (type=injection, target risk=0.5, medium length, severe anomaly).

[0117] The feature vector of D3 (controlling screen brightness) is E3=(3,0.2,0.1,0) (type=control, target risk=0.2, short length, normal).

[0118] Converting the message's "semantics" into "numerical values" facilitates subsequent processing through similarity calculations and model predictions, thus addressing the issue that "text-based messages cannot directly participate in algorithmic operations."

[0119] S030, based on the similarity between each message feature vector in E and the preset historical message feature vectors, determine the message feature words corresponding to each message to be executed in D, so as to obtain the message feature word list F = (F1, F2, ..., F3) corresponding to D. x F y ); F x D x The corresponding message feature words; each historical message feature vector corresponds to one message feature word.

[0120] Furthermore, step S030 includes the following steps:

[0121] S031, Obtain E x The similarity between the data and each preset historical message feature vector.

[0122] S032, if E x If the highest similarity (RE) among the similarities between each preset historical message feature vector and the target historical message feature vector is greater than or equal to a second preset similarity threshold, then the historical message feature vector corresponding to the RE is determined as the target historical message feature vector; otherwise, the current processing is terminated.

[0123] S033, determine the message feature words corresponding to the target historical message feature vector as F. x .

[0124] In this embodiment, the historical message feature vector library consists of feature vectors of various typical messages from historical tests, with each vector associated with one "message feature word" (semantic tag). As shown in Table 3:

[0125] Table 3

[0126]

[0127] Calculate the current message feature vector E x The cosine similarity with all historical vectors; the second preset similarity threshold can be set according to the strictness of message matching, for example: the second preset similarity threshold is set to 0.7; after matching all messages in D, F = ("CPU normal query", "navigation abnormal injection", "screen normal control",...).

[0128] By using feature words to uniformly describe similar messages (such as different batches of "navigation anomaly injection" messages all corresponding to the same feature word), consistent input is provided for subsequent sequence modeling of the N-Gram model.

[0129] S040, input F into the preset second N-Gram model to predict whether the next message DZ to be executed entering the first-in-first-out queue is a restart message.

[0130] Training the second N-Gram model: Based on historical samples of "message feature word sequence → whether it follows a restart message", for example:

[0131] Historical sequence 1: (“CPU normal query”, “navigation anomaly injection”) → the next message is a “hard reboot message” (probability 0.8);

[0132] Historical sequence 2: ("Screen normal control", "Memory query") → The next message is not a restart message (probability 0.9).

[0133] The model uses 2-Gram, and its core calculation is "the probability that the next message is a restart message when the first y feature word sequences appear".

[0134] Prediction process: Input F=(“CPU normal query”, “Navigation abnormal injection”, “Screen normal control”) into the model. The model calculates that “the probability that the next message DZ is a hard reboot message = 0.85” (greater than the preset probability threshold of 0.7). Therefore, it is predicted that DZ is a reboot message.

[0135] This step allows for the advance prediction of restart needs. Before restart messages actually enter the queue, their probability of occurrence can be predicted based on historical patterns, providing a basis for subsequent preset restart instructions and reducing the computational cost of "temporary decisions".

[0136] S050, if DZ is a restart message, then insert the restart instruction CQ corresponding to the restart message after the last message to be executed in the first-in-first-out queue; proceed to S060.

[0137] If S040 predicts that DZ is a "hard reboot message", then insert the corresponding reboot instruction CQ after the last message in the current queue (such as D4): {Type: reboot, Method: hard reboot, Execution time: to be determined} (the execution time will be determined in S060).

[0138] After insertion, the queue becomes (D1, D2, D3, D4, CQ), ensuring that the restart command is executed after the existing test sequence (without interrupting the original test logic).

[0139] This step allows for the preparation of restart commands in advance, avoiding delays caused by generating commands on short notice when a restart is needed. At the same time, queue insertion ensures the continuity between the restart operation and preceding tests.

[0140] S060, when the preset time point is reached, proceed to S100; the preset time point is the time point before the execution time point TQ of the last message to be executed in the first-in-first-out queue and the time interval between it and TQ is T.

[0141] Preset time point calculation: Suppose the execution time of the last message to be executed in the queue (such as D4) is TQ=10:00:20, and the preset time interval T=10 seconds (sufficient time to execute S100-S400), then the preset time point = 10:00:20 - 10 seconds = 10:00:10.

[0142] Triggering logic: When the system time reaches 10:00:10, S100-S400 will be executed automatically (collecting the waveform of running data within T=10 seconds and generating a restart label) to ensure that real-time verification is completed before D4 is finished.

[0143] Real-time analysis is performed before the last message is executed, which ensures that there is enough data to determine whether a restart is needed, and avoids test interruption caused by excessive waiting time for restart commands.

[0144] S070, based on the result corresponding to the restart tag in S400, determine whether to send CQ to the target vehicle system.

[0145] Furthermore, step S070 includes the following steps:

[0146] S071, if the restart label in S400 corresponds to a restart command, then CQ is sent to the target vehicle unit to control the target vehicle unit to perform a restart operation.

[0147] If the S400's restart label corresponds to a restart command (such as "hard reboot"), then a CQ (preset hard reboot command) is sent to control the vehicle's infotainment system to execute it. For example, if the S400 predicts that a hard reboot is needed and CQ is a hard reboot command, then CQ is sent, and the vehicle's infotainment system will immediately execute the hard reboot after D4 (10:00:20).

[0148] Furthermore, the restart instructions corresponding to the restart message include soft restart instructions and hard restart instructions; the restart instructions corresponding to the restart tag include soft restart instructions and hard restart instructions.

[0149] The reboot command type is divided into "soft reboot" (only reboots the system layer and retains data) and "hard reboot" (power off reboot and restores the initial state). It is necessary to verify whether the reboot label type of S400 is consistent with the CQ type.

[0150] Furthermore, step S071 may include the following steps:

[0151] S71, if the restart label in S400 corresponds to a restart instruction and the restart instruction corresponding to the restart label is of the same type as the restart instruction corresponding to CQ, then CQ is sent to the target vehicle unit to control the target vehicle unit to perform a restart operation.

[0152] If the S400 tag is "soft reboot" and the CQ is also a "soft reboot command", then send the CQ. For example: if the CQ is predicted to be a soft reboot, and real-time verification also requires a soft reboot, then execute the sending.

[0153] S72, if the restart label in S400 corresponds to a restart instruction and the type of the restart instruction corresponding to the restart label is different from the type of the restart instruction corresponding to CQ, then a manual restart prompt is generated.

[0154] If the S400 label is "hard reboot" but the CQ is "soft reboot command", a manual selection prompt will be generated (e.g., "Predicted soft reboot, but hard reboot is required in real time. Please confirm the execution type"), and the tester will decide on the final command.

[0155] S072, if the restart label in S400 corresponds to a non-restart command, then CQ will not be sent to the target vehicle system.

[0156] If the S400's restart label is "No restart required," then no CQ will be sent. For example, if the S400 analysis finds that the vehicle's infotainment system is in normal condition and does not require a restart, the preset CQ will be discarded to avoid invalid operations.

[0157] By following the steps above, we can avoid the risks caused by type errors: hard reboots may lose test data, soft reboots may not be able to solve deep problems, and type matching checks can reduce test bias caused by "instruction type errors"; human-machine collaborative optimization decision-making: when predictions conflict with real-time results, human judgment is introduced to balance automation efficiency and decision-making accuracy in complex scenarios.

[0158] The above steps have at least the following beneficial effects:

[0159] Reduce computing power consumption: Predict restart requirements in advance through S010-S040, and only execute S100-S500 (real-time verification) when a restart is predicted to be possible, avoiding the waste of computing power caused by "indiscriminate and frequent execution" in the original method (especially in low-aggression test scenarios).

[0160] Improve the accuracy of restart timing: Through FIFO queue management and preset time point design, ensure that the restart command is executed "after the preceding test is completed and the status is abnormal", so as to avoid interrupting the test process or missing key verification nodes.

[0161] Enhanced decision reliability: The triple logic of "prediction (second N-Gram) + real-time verification (first N-Gram) + type matching check" significantly reduces the probability of erroneous / missed restart commands, overcoming the limitations of traditional single-logic decision-making.

[0162] Adaptable to complex testing scenarios: By providing prompts through manual selection, it retains room for human intervention when predictions conflict with real-time results, balancing automation efficiency with the rigor of testing in special scenarios.

[0163] In this embodiment, by acquiring the time-series waveforms of various operating data of the target vehicle's infotainment system within a preset historical time period, matching the corresponding operating data feature words with the historical time-series waveform list, and then using a preset N-Gram model to generate a restart command, the restart operation is transformed from manual intervention or random triggering to intelligent and precise triggering. Specifically, compared with the existing technology that relies on staff to actively set time nodes, this method can dynamically determine the restart timing based on the real-time operating data of the vehicle's infotainment system without manual intervention, greatly reducing labor costs and avoiding test deviations caused by differences in human experience. Addressing the limitations of random restart triggering in fuzzy testing, this method generates restart commands by analyzing the actual operating state characteristics of the vehicle's infotainment system, accurately capturing key operating states and triggering restarts in a targeted manner. This avoids omissions in testing key states and reduces repetitive testing of non-critical states, thereby comprehensively improving the completeness and relevance of test coverage. Simultaneously, this intelligent triggering method based on data features can dynamically adjust the restart strategy according to changes in the operating state of the vehicle's infotainment system, effectively improving testing efficiency in scenarios such as fuzzy testing, and better adapting to the needs of complex vehicle infotainment systems for comprehensive and efficient testing.

[0164] Furthermore, although the steps of the method in this disclosure are described in a specific order in the accompanying drawings, this does not require or imply that the steps must be performed in that specific order, or that all the steps shown must be performed to achieve the desired result. Additional or alternative steps may be omitted, multiple steps may be combined into one step, and / or a step may be broken down into multiple steps.

[0165] Embodiments of the present invention also provide a non-transitory computer-readable storage medium that can be disposed in an electronic device to store at least one instruction or at least one program related to implementing a method in the method embodiments, wherein the at least one instruction or the at least one program is loaded and executed by the processor to implement the method provided in the above embodiments.

[0166] The program product may employ any combination of one or more readable media. A readable medium may be a readable signal medium or a readable storage medium. A readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of readable storage media (a non-exhaustive list) include: an electrical connection having one or more wires, a portable disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0167] Computer-readable signal media may include data signals propagated in baseband or as part of a carrier wave, carrying readable program code. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A readable signal medium may also be any readable medium other than a readable storage medium, capable of sending, propagating, or transmitting programs for use by or in conjunction with an instruction execution system, apparatus, or device.

[0168] The program code contained on the readable medium may be transmitted using any suitable medium, including but not limited to wireless, wired, optical fiber, RF, etc., or any suitable combination thereof.

[0169] Program code for performing the operations of this application can be written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Java and C++, and conventional procedural programming languages ​​such as C or similar languages. The program code can execute entirely on the user's computing device, partially on the user's device, as a standalone software package, partially on the user's computing device and partially on a remote computing device, or entirely on a remote computing device or server. In cases involving remote computing devices, the remote computing device can be connected to the user's computing device via any type of network, including a local area network (LAN) or a wide area network (WAN), or it can be connected to an external computing device (e.g., via the Internet using an Internet service provider).

[0170] Embodiments of the present invention also provide an electronic device, including a processor and the aforementioned non-transitory computer-readable storage medium.

[0171] The electronic device is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments in this application.

[0172] Electronic devices are manifested in the form of general-purpose computing devices. Components of an electronic device may include, but are not limited to: at least one processor, at least one memory, and a bus connecting different system components (including memory and processor).

[0173] The memory stores program code that can be executed by the processor, causing the processor to perform the steps in the various embodiments described in this specification.

[0174] The memory may include readable media in the form of volatile memory, such as random access memory (RAM) and / or cache memory, and may further include read-only memory (ROM).

[0175] The memory may also include programs / utilities having a set (at least one) of program modules, including but not limited to: an operating system, one or more application programs, other program modules, and program data, each or some combination of these examples may include an implementation of a network environment.

[0176] A bus can represent one or more of several types of bus structures, including a memory bus or memory controller, a peripheral bus, a graphics acceleration port, a processor, or a local bus that uses any of the various bus structures.

[0177] Electronic devices can also communicate with one or more external devices (e.g., keyboards, pointing devices, Bluetooth devices, etc.), one or more devices that enable user interaction with the electronic device, and / or any device that enables the electronic device to communicate with one or more other computing devices (e.g., routers, modems, etc.). This communication can be achieved through input / output (I / O) interfaces. Furthermore, electronic devices can communicate with one or more networks (e.g., local area networks (LANs), wide area networks (WANs), and / or public networks, such as the Internet) via network adapters. The network adapter communicates with other modules of the electronic device via a bus. It should be understood that other hardware and / or software modules can be used in conjunction with the electronic device, including but not limited to: microcode, device drivers, redundant processors, external disk drive arrays, RAID systems, tape drives, and data backup storage systems.

[0178] From the above description of the embodiments, those skilled in the art will readily understand that the exemplary embodiments described herein can be implemented by software or by combining software with necessary hardware. Therefore, the technical solutions according to the embodiments of this disclosure can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (such as a CD-ROM, USB flash drive, external hard drive, etc.) or on a network, including several instructions to cause a computing device (such as a personal computer, server, terminal device, or network device, etc.) to execute the methods according to the embodiments of this disclosure.

[0179] Embodiments of the present invention also provide a computer program product including program code, which, when the program product is run on an electronic device, causes the electronic device to perform the steps of the methods described above in various exemplary embodiments of the present invention.

[0180] While specific embodiments of the invention have been described in detail by way of examples, those skilled in the art should understand that the examples are for illustrative purposes only and are not intended to limit the scope of the invention. Those skilled in the art should also understand that various modifications can be made to the embodiments without departing from the scope and spirit of the invention.

Claims

1. A method for remotely testing and rebooting a vehicle head unit, the method comprising: The method comprises the following steps: S100, obtaining time sequence waveforms of each type of running data of the target car machine in a preset historical time period T to obtain a time sequence waveform list A=(A1, A2, …, A i , …, A n ), i=1, 2, …, n; A i is the time sequence waveform corresponding to the ith type of running data, and n is the number of types of running data of the target car machine; S200, obtaining a historical time sequence waveform list L corresponding to the i-th type of operation data i = (L i，1 , L i，2 , …, L i，j , …, L i，f（i） ), L i，j is the j-th historical time sequence waveform corresponding to the i-th type of operation data, f(i) is the number of historical time sequence waveforms corresponding to the i-th type of operation data; each historical time sequence waveform corresponds to a standard operation data characteristic word; S300, according to A i With L i Similarity between each historical time sequence waveform, determine A i Corresponding operation data characteristic word B i , and then get A corresponding operation data characteristic word list B= (B1, B2, …, B i , …, B n ); S400, input B into a preset first N-Gram model for target vehicle machine restart instruction prediction to generate a restart label corresponding to the target vehicle machine; S500, if the restart label corresponds to a restart instruction, send the restart instruction corresponding to the restart label to the target vehicle machine to control the target vehicle machine to execute a restart operation corresponding to the restart instruction; otherwise, do not send the restart instruction to the target vehicle machine.

2. The method of claim 1, wherein, Step S300 comprises the following steps: S310, according to L i characteristic vectors corresponding to each historical time sequence waveform in L i , the historical time sequence waveforms in L i are clustered to obtain a cluster list C=(C1, C2, …, C p , …, C q ), p=1, 2, …, q; C p is the pth cluster obtained by clustering the historical time sequence waveforms in L i , and q is the number of clusters obtained by clustering the historical time sequence waveforms in L i . S320, obtaining A i corresponding feature vector XL i similarity between the center vectors corresponding to each cluster in C, to obtain XL i corresponding similarity list η i = (η i，1 , η i，2 , …, η i，p , …, η i，q ); η i，p is the similarity between XL i and C p ​ S330, if the maximum similarity η i in the η i，max is greater than or equal to QR, then randomly determine η i，max ; otherwise, jump out of the current processing; QR is a first preset similarity threshold. i ; otherwise, jump out of the current processing; QR is a first preset similarity threshold.

3. The method of claim 2, wherein the remote test reboot of the vehicle head unit is initiated by a user of the vehicle head unit. QR is determined by the following steps: S331, obtain the injection intensity S and the injection risk level R of the current test case of the target vehicle machine; S is determined by the amount, frequency and proportion of abnormal data of the input data corresponding to the test case; R is determined by the type of the test case; 0≤S≤1; 0≤R≤1; S332, determine the degree of aggressiveness K=α×S+β×R corresponding to the current test case according to S and R; wherein, α is the injection intensity weight, and β is the injection risk level weight; α+β=1; S333, determining QR = QR according to K base × (1 - K × γ); wherein, QR base is a preset basic threshold; γ is a preset adjustment coefficient; 0 < γ < 1.

4. The method of claim 1, wherein the remote test reboot of the vehicle head unit is initiated by a user of the vehicle head unit. Before step S100, the method further comprises the following steps: S010, whenever a new to-be-executed packet is added in the preset first-in-first-out queue, obtaining each to-be-executed packet in the first-in-first-out queue to obtain a to-be-executed packet list D=(D1, D2, …, Dy), x=1, 2, …, y; Dx is the xth to-be-executed packet in the first-in-first-out queue, and y is the length of the first-in-first-out queue. x , …, D y ), x=1, 2, …, y; Dx is the xth to-be-executed packet in the first-in-first-out queue, and y is the length of the first-in-first-out queue. x ​ S020, perform feature encoding on each message to be executed in D to obtain the message feature vector list E = (E1, E2, ..., E...). x , ..., E y ); E x D x The corresponding message feature vector; S030, according to the similarity between each message feature vector in E and the preset historical message feature vector, determining the message feature word corresponding to each to-be-executed message in D to obtain the message feature word list F=(F1, F2, …, F x , …, F y ) corresponding to D; F x is the message feature word corresponding to D x ; each historical message feature vector corresponds to a message feature word; S040, input F into a preset second N-Gram model to predict whether the to-be-executed packet DZ entering the first-in-first-out queue next is a restart packet; S050, if DZ is a restart packet, insert the restart instruction CQ corresponding to the restart packet after the last to-be-executed packet in the first-in-first-out queue; enter S060; S060, when reaching a preset time point, enter S100; the preset time point is a time point before the execution time point TQ of the last to-be-executed packet in the first-in-first-out queue and the time interval with TQ is T; S070, determine whether to send CQ to the target vehicle machine according to the result corresponding to the restart label in S400.

5. The method of claim 4, wherein, Step S070 comprises the following steps: S071, if the restart label in S400 corresponds to a restart instruction, send CQ to the target vehicle machine to control the target vehicle machine to execute a restart operation; S072, if the restart label in S400 corresponds to a non-restart instruction, do not send CQ to the target vehicle machine.

6. The method of claim 4, wherein, Step S030 comprises the following steps: S031, obtaining E x a similarity between each preset historical message feature vector; S032, if E x If the maximum similarity RE between each preset historical message feature vector is greater than or equal to a second preset similarity threshold, the historical message feature vector corresponding to RE is determined as the target historical message feature vector; otherwise, the current processing is exited. S033, determine the message feature word corresponding to the target historical message feature vector as F x .

7. The method of claim 5, wherein the remote test reboot of the vehicle head unit is initiated by a user of the vehicle head unit. The restart instruction corresponding to the restart packet comprises a soft restart instruction and a hard restart instruction; the restart instruction corresponding to the restart label comprises a soft restart instruction and a hard restart instruction.

8. The method of claim 7, wherein, Step S071 comprises the following steps: S71, if the restart label in S400 corresponds to a restart instruction and the restart instruction corresponding to the restart label is of the same type as the restart instruction corresponding to CQ, send CQ to the target vehicle machine to control the target vehicle machine to execute a restart operation; S72, if the restart label in S400 corresponds to a restart instruction and the restart instruction corresponding to the restart label is of a different type from the restart instruction corresponding to CQ, generate an artificial selection restart prompt. 9.A non-transitory computer-readable storage medium having stored therein at least one instruction or at least one piece of program, characterized in that, The at least one instruction or the at least one program is loaded and executed by the processor to implement the remote test restart method of the vehicle machine as claimed in any one of claims 1-8.

10. An electronic device, comprising: The processor and the non-transitory computer readable storage medium of claim 9. The processor and the non-transitory computer readable storage medium of claim 9.

Images