Alarm test method, device and equipment of vehicle-to-everything cloud platform and medium

Abstract

Embodiments of the present application provide a kind of vehicle networking cloud platform's alarm test method, device, equipment and medium.The method comprises: according to the self-defined alarm rule of cloud platform, the vehicle parameter and signal parameter of target test scene are determined;The vehicle parameter includes vehicle type and OTA version;The signal parameter includes signal source, target signal keyword and target signal alarm range;At least one test signal corresponding to the self-defined alarm rule is generated based on the vehicle parameter and signal parameter;The cloud platform is tested for alarm using the at least one test signal.The method is used to realize the dynamic extension of test scene, to improve the scene coverage of cloud alarm test effect.

Description

Technical Field

[0001] This application relates to the field of vehicle networking, and in particular to an alarm testing method, apparatus, equipment and medium for a vehicle networking cloud platform. Background Technology

[0002] With the rapid development of vehicle-to-everything (V2X) technology, vehicles use onboard sensors, communication modules, and other devices to collect and upload signal data to cloud platforms in real time. This forms the core foundation for functions such as vehicle status monitoring, fault warning, and over-the-air (OTA) upgrades. The cloud platform needs to analyze massive amounts of vehicle signal data to detect abnormal conditions (such as engine failure, battery overheating, etc.) and trigger alarms.

[0003] During actual testing, the platform's alarm module needs to verify its accuracy and stability by simulating real vehicle signal data. For example, when developing new vehicle models or upgrading platform functions, it is necessary to verify whether the alarm rules can cover complex scenarios (such as extreme weather, sudden failures, etc.) and whether the platform can maintain performance under high-concurrency data.

[0004] Existing testing methods typically generate test signal data based on pre-defined scenario rules. However, these pre-defined rules only cover a limited number of scenarios and are difficult to adapt to the needs of vehicle model iterations and alarm rule upgrades, resulting in incomplete test coverage. Therefore, there is an urgent need for a technology to improve the scenario coverage of alarm testing on cloud platforms. Summary of the Invention

[0005] This application provides an alarm testing method, apparatus, device, and medium for a vehicle network cloud platform, which enables dynamic expansion of test scenarios, thereby improving the scenario coverage of cloud alarm testing.

[0006] In a first aspect, embodiments of this application provide an alarm testing method for a vehicle-to-everything (V2X) cloud platform, including:

[0007] Based on the custom alarm rules of the cloud platform, determine the vehicle parameters and signal parameters of the target test scenario; the vehicle parameters include the vehicle model and OTA version; the signal parameters include the signal source, target signal keywords, and target signal alarm range.

[0008] Based on the vehicle parameters and signal parameters, at least one test signal corresponding to the custom alarm rule is generated.

[0009] The cloud platform is tested for alarms using at least one of the test signals.

[0010] In one possible implementation, generating at least one test signal corresponding to the custom alarm rule based on the vehicle parameters and signal parameters includes:

[0011] Obtain a signal list and a signal definition file corresponding to the vehicle parameters and the signal source; the signal definition file includes the signal value range corresponding to each signal keyword in the signal list.

[0012] The vehicle identifiers that match the vehicle parameters are filtered from the vehicle information table; the vehicle information table includes information about vehicles managed by the cloud platform.

[0013] Based on the signal list, the signal definition file, the target signal keyword, the target signal alarm range, and the vehicle identifier, at least one test signal corresponding to the custom alarm rule is generated.

[0014] In one possible implementation, generating at least one test signal corresponding to the custom alarm rule based on the signal list, the signal definition file, the target signal keyword, the target signal alarm range, and the vehicle identifier includes:

[0015] By determining the signal value of each signal keyword in the signal list according to the signal definition file, at least one initial full signal is obtained;

[0016] For each initial full signal, the signal value corresponding to the target signal keyword in the initial full signal is adjusted according to the test purpose and the target signal alarm range to obtain a single full signal corresponding to the initial full signal.

[0017] The vehicle identifier is combined with each individual full signal to obtain the at least one test signal;

[0018] The test objectives include the expectation that the test signal will trigger an alarm on the cloud platform and the expectation that the test signal will not trigger an alarm on the cloud platform.

[0019] In one possible implementation, adjusting the signal value corresponding to the target signal keyword in the initial full signal according to the test objective and the target signal alarm range includes:

[0020] If the purpose of the test is to expect the test signal to trigger an alarm on the cloud platform, then the signal value corresponding to the target signal keyword in the initial full signal is adjusted to any value within the target signal alarm range.

[0021] If the purpose of the test is to prevent the test signal from triggering an alarm on the cloud platform, then the signal value corresponding to the target signal keyword in the initial full signal is adjusted to any value outside the target signal alarm range.

[0022] In one possible implementation, the step of obtaining at least one initial full signal by determining the signal value of each signal keyword in the signal list according to the signal definition file includes:

[0023] For each signal keyword in the signal list, at least one random number is generated within the signal value range corresponding to the signal keyword in the signal definition file using a random function;

[0024] The at least one initial full signal is obtained by assigning a value to the signal value of each signal keyword in the signal list according to at least one random number corresponding to each signal keyword.

[0025] In one possible implementation, the signal parameters further include the signal reporting period and reporting duration; the step of using the at least one test signal to perform alarm testing on the cloud platform includes:

[0026] Generate a test signal sequence based on the at least one test signal;

[0027] According to the reporting cycle and the reporting duration, the test signal sequence is reported to the cloud platform, and the alarm results of the cloud platform are collected.

[0028] In one possible implementation, reporting the test signal sequence to the cloud platform according to the reporting period and the reporting duration includes:

[0029] Set a timer according to the reported duration and start the countdown;

[0030] During the countdown, each test signal in the test signal sequence is reported to the cloud platform in sequence according to the reporting period.

[0031] Secondly, embodiments of this application provide an alarm testing device for a vehicle-to-everything (V2X) cloud platform, comprising:

[0032] The determination module is used to determine the vehicle parameters and signal parameters of the target test scenario based on the custom alarm rules of the cloud platform; the vehicle parameters include the vehicle model and OTA version; the signal parameters include the signal source, the target signal keyword, and the target signal alarm range.

[0033] The generation module is used to generate at least one test signal corresponding to the custom alarm rule based on the vehicle parameters and signal parameters.

[0034] The testing module is used to perform alarm tests on the cloud platform using at least one test signal.

[0035] In one possible implementation, the generation module includes:

[0036] The acquisition unit is used to acquire a signal list and a signal definition file corresponding to the vehicle parameters and the signal source; the signal definition file includes the signal value range corresponding to each signal keyword in the signal list.

[0037] A filtering unit is used to filter vehicle identifiers that match the vehicle parameters from a vehicle information table; the vehicle information table includes information about vehicles managed by the cloud platform.

[0038] The first generation unit is used to generate at least one test signal corresponding to the custom alarm rule based on the signal list, the signal definition file, the target signal keyword, the target signal alarm range, and the vehicle identifier.

[0039] In one possible implementation, the first generating unit includes:

[0040] The acquisition subunit is used to acquire at least one initial full signal by determining the signal value of each signal keyword in the signal list according to the signal definition file;

[0041] The adjustment subunit is used to adjust the signal value corresponding to the target signal keyword in the initial full signal according to the test purpose and the target signal alarm range for each initial full signal, so as to obtain a single full signal corresponding to the initial full signal.

[0042] A combination subunit is used to combine the vehicle identifier with each individual full signal to obtain the at least one test signal;

[0043] The test objectives include the expectation that the test signal will trigger an alarm on the cloud platform and the expectation that the test signal will not trigger an alarm on the cloud platform.

[0044] In one possible implementation, the adjustment subunit is specifically used for:

[0045] If the purpose of the test is to expect the test signal to trigger an alarm on the cloud platform, then the signal value corresponding to the target signal keyword in the initial full signal is adjusted to any value within the target signal alarm range.

[0046] If the purpose of the test is to prevent the test signal from triggering an alarm on the cloud platform, then the signal value corresponding to the target signal keyword in the initial full signal is adjusted to any value outside the target signal alarm range.

[0047] In one possible implementation, the generating unit is specifically used for:

[0048] For each signal keyword in the signal list, at least one random number is generated within the signal value range corresponding to the signal keyword in the signal definition file using a random function;

[0049] The at least one initial full signal is obtained by assigning a value to the signal value of each signal keyword in the signal list according to at least one random number corresponding to each signal keyword.

[0050] In one possible implementation, the test module includes:

[0051] The second generation unit is used to generate a test signal sequence based on the at least one test signal;

[0052] The reporting unit is used to report the test signal sequence to the cloud platform according to the reporting cycle and the reporting duration, and to collect the alarm results of the cloud platform.

[0053] In one possible implementation, the reporting unit is specifically used for:

[0054] Set a timer according to the reported duration and start the countdown;

[0055] During the countdown, each test signal in the test signal sequence is reported to the cloud platform in sequence according to the reporting period.

[0056] Thirdly, embodiments of this application provide a computer device, including: a memory and a processor;

[0057] The memory stores computer-executed instructions;

[0058] The processor executes computer execution instructions stored in the memory, causing the processor to perform the first aspect and / or various possible implementations of the first aspect as described above.

[0059] Fourthly, embodiments of this application provide a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the first aspect and / or various possible implementations of the first aspect.

[0060] Fifthly, embodiments of this application provide a computer program product, including a computer program that, when executed by a processor, implements the first aspect and / or various possible implementations of the first aspect.

[0061] The alarm testing method, apparatus, device, and medium for the vehicle-to-everything (V2X) cloud platform provided in this application embodiment first clarifies the vehicle parameters and signal parameters corresponding to the target test scenario from the cloud platform's own custom alarm rules, then generates at least one test signal adapted to the rules based on the vehicle parameters and signal parameters, and finally uses at least one test signal to conduct alarm function testing on the cloud platform. This means that the generation of test signals no longer depends on fixed preset scenario rules, but adapts synchronously with the update of the cloud platform's custom alarm rules and the iteration rhythm of vehicle models. It can flexibly cover alarm test scenarios corresponding to different vehicle models, different OTA versions, and various signal sources, thereby significantly improving the scenario coverage of alarm testing for the V2X cloud platform. Attached Figure Description

[0062] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0063] Figure 1 A flowchart illustrating an alarm testing method for a vehicle networking cloud platform provided in Embodiment 1 of this application;

[0064] Figure 2 This is a flowchart illustrating an alarm testing method for a vehicle-to-everything (V2X) cloud platform provided in Embodiment 2 of this application.

[0065] Figure 3 This is a flowchart illustrating an alarm testing method for a vehicle-to-everything (V2X) cloud platform provided in Embodiment 3 of this application.

[0066] Figure 4 This is a schematic diagram of the structure of an alarm testing device for a vehicle networking cloud platform provided in Embodiment 4 of this application;

[0067] Figure 5 A schematic diagram of the structure of the computer device provided in this application.

[0068] The accompanying drawings illustrate specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to particular embodiments. Detailed Implementation

[0069] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0070] To facilitate understanding of the technical content of this solution, the background technology is described in detail below:

[0071] With the deep integration of the automotive industry with big data, artificial intelligence (AI), and the Internet of Things (IoT), vehicle-to-everything (V2X) platforms have entered a stage of rapid development. This enables vehicles to collect and upload signal data to the cloud platform in real time through onboard sensors, communication modules, and other devices, becoming the core foundation for realizing functions such as vehicle status monitoring, fault warning, and over-the-air (OTA) upgrades.

[0072] In terms of fault early warning, the cloud platform analyzes massive amounts of vehicle signal data and performs fault location, effectively shortening the fault diagnosis cycle and significantly reducing the cost of vehicle maintenance. Against this backdrop, the vehicle signal data testing and verification module has become a core technology module for ensuring the quality of the vehicle-to-everything (V2X) platform, possessing significant technical value and application significance. During the alarm function testing phase of the cloud platform, the platform's alarm module needs to verify its accuracy and stability by simulating real vehicle signal data.

[0073] The scenario coverage of the simulated signal data is crucial to the comprehensiveness of functional testing. Existing testing methods typically generate signal data based on pre-defined scenario rules. For example, by setting vehicle trip frequency, driving type, and signal configuration parameters, a trip plan is randomly generated, and test signals are generated accordingly. However, this method relies on pre-defined rules, which can only cover a limited number of scenarios and are difficult to adapt to the needs of vehicle model iteration and alarm rule upgrades, exhibiting poor scenario scalability. This leads to incomplete test scenario coverage. Furthermore, the realism of the simulated signal data is critical to the reliability of functional test results; improving the realism of simulated signals is also an important direction for current research.

[0074] Based on the aforementioned background technology, the inventors discovered during their research that they could directly start from custom alarm rules, and decompose vehicle parameters and signal parameters corresponding to the target test scenario and conforming to the actual vehicle operating characteristics according to the custom alarm rules. These parameters would then serve as dual constraints to generate standardized test signals, and signal injection would complete the full-process validity verification of the alarm rules on the cloud platform. In view of this, this application proposes an alarm testing method, device, equipment, and medium for a vehicle-to-everything (V2X) cloud platform to achieve dynamic expansion of test scenarios, thereby improving the scenario coverage of cloud-based alarm testing.

[0075] It should be noted that this application applies to the development and testing scenarios of vehicle networking platforms, specifically including program reliability verification of vehicle alarm modules, performance testing of the platform's high-concurrency signal processing capabilities, and signal compatibility testing before the release of new models or OTA versions. In terms of network architecture, the cloud platform interacts with the vehicle through communication modules (such as 5G, Cellular Vehicle-to-Everything (C-V2X), etc.), receiving real-time signal data and triggering alarm rules. The testing tools are deployed in the cloud and dynamically generate simulation signals according to testing requirements, simulating vehicle reporting behavior and verifying the platform's stability and accuracy in complex scenarios. For example, in extreme weather simulations, the tools can generate abnormal test signals to trigger the platform's alarm module's response logic, thereby ensuring that it can promptly identify faults in real-world deployments.

[0076] The technical solution of this application and how the technical solution of this application solves the above-mentioned technical problems are described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will now be described with reference to the accompanying drawings.

[0077] Figure 1 This is a flowchart illustrating an alarm testing method for a vehicle-to-everything (V2X) cloud platform provided in Embodiment 1 of this application. Figure 1 As shown, the alarm testing method for the vehicle-to-everything (V2X) cloud platform provided in this embodiment includes:

[0078] S101. Based on the custom alarm rules of the cloud platform, determine the vehicle parameters and signal parameters of the target test scenario.

[0079] Specifically, custom alarm rules refer to signal alarm rules defined by the developers or maintenance personnel of the vehicle-to-everything (V2X) cloud platform, based on the vehicle requirements of automakers, fault warning scenarios, and vehicle hardware characteristics. These rules are used to identify anomalies in reported vehicle signals and trigger alarms when an anomaly is detected. It should be understood that in practical applications, different vehicle parameters typically result in different alarm rules for the same type of signal. Therefore, custom alarm rules must specify the applicable vehicle parameters when defining them.

[0080] The target test scenario refers to the scenario that the user intends to conduct signal alarm tests. This step defines the vehicle parameters and signal parameters in the test scenario based on the custom alarm rules. Among them, vehicle parameters include vehicle model and OTA version; signal parameters include signal source, target signal keyword, and target signal alarm range.

[0081] In detail, vehicle model refers to the specific model classification of the vehicle; OTA version refers to the software version number of the vehicle's onboard system. It should be understood that, in order to adapt to technological changes, different OTA versions of the same vehicle model may have different alarm logic for signals; target signal keyword refers to the name of the signal to be monitored in the custom alarm rule; target signal alarm range refers to the range within which the signal value of the target signal keyword specified in the custom alarm rule triggers an alarm.

[0082] Additionally, the signal source refers to the transmission source of the signal corresponding to the target signal keyword. It should be understood that in the actual signal reporting phase, the vehicle typically reports all signals managed by the signal source to the cloud platform in full signal form. Therefore, to further improve the realism of the simulated test signal, it is also necessary to obtain the signal source of the corresponding signal in the target scenario. For example, national standard signals (such as vehicle speed signals, power battery temperature signals, etc., which strictly adhere to national or industry-standard definitions) are uniformly sent to the cloud platform through the national standard communication bridge platform (DCBP), while default signals (such as seat adjustment position, interior light switch status, etc., which are manufacturer-defined signals) are uniformly sent to the cloud platform through the manufacturer's self-developed equipment acquisition and forwarding nodes.

[0083] For example, custom alarm rule 1 in the cloud platform indicates that the alarm range for the battery temperature signal of vehicle model A with version number v2.1 is greater than 60°C, where the signal source of the battery temperature signal is DCBP. Accordingly, according to custom alarm rule 1, the target test scenario can be determined as vehicle model A, OTA version v2.1, signal source DCBP, target signal keyword battery temperature, and target signal alarm range greater than 60°C.

[0084] S102. Based on vehicle parameters and signal parameters, generate at least one test signal corresponding to the custom alarm rule.

[0085] In this step, the reasonableness of the signal values ​​in the test signals will be constrained using vehicle parameters and signal parameters, and the signal values ​​will be encapsulated into a test signal that conforms to the actual reporting rules of the vehicle. It should be understood that by changing the magnitude of the signal values ​​under the guidance of this principle, multiple test signals can be obtained, and each test signal can verify the effectiveness of the alarm function of the cloud platform in the target test scenario.

[0086] S103. Use at least one test signal to perform an alarm test on the cloud platform.

[0087] In this step, it is necessary to simulate the signal reporting process from the vehicle to the cloud platform based on at least one test signal, and collect the actual alarm status of the cloud platform in response to the simulated signal; compare the actual alarm status with the user's expected alarm status to realize the functional test of the cloud platform for the custom alarm rule (such as false alarm rate or false alarm rate).

[0088] The alarm testing method for the vehicle-to-everything (V2X) cloud platform provided in this application first clarifies the vehicle parameters and signal parameters corresponding to the target test scenario from the cloud platform's own custom alarm rules. Then, based on the vehicle parameters and signal parameters, it generates at least one test signal that adapts to the rules. Finally, it uses at least one test signal to conduct alarm function testing on the cloud platform. This means that the generation of test signals no longer depends on fixed preset scenario rules, but rather adapts synchronously with the update rhythm of the cloud platform's custom alarm rules and the iteration rhythm of vehicle models. It can flexibly cover alarm test scenarios corresponding to different vehicle models, different OTA versions, and various signal sources, achieving a significant improvement in the scenario coverage of V2X cloud platform alarm testing. At the same time, this solution also ensures that the alarm testing is closely aligned with the custom alarm rules that are actually in effect on the cloud. The test signals can accurately match the actual technical configuration requirements of different vehicle models, different OTA versions, and corresponding signal sources, avoiding the problem of test signals deviating from actual alarm rules and being incompatible with the actual attributes of vehicles and signals. This achieves the effect of improving the accuracy and scenario fit of V2X cloud platform alarm testing.

[0089] Furthermore, Figure 2 This is a flowchart illustrating an alarm testing method for a vehicle-to-everything (V2X) cloud platform provided in Embodiment 2 of this application. Figure 2 As shown, based on the above embodiments, this embodiment provides a detailed description of the specific implementation of step S102 in the aforementioned embodiments, specifically including:

[0090] S1021. Obtain the signal list and signal definition file corresponding to the vehicle parameters and signal sources.

[0091] In this step, since the cloud platform receives the full signal packaged and sent by the signal source in actual signal reporting scenarios, to further improve the realism of the simulated test signal, a signal list corresponding to the vehicle parameters and signal source configured in the cloud platform will be obtained. This signal list includes the corresponding vehicle model and OTA version. The signal source is responsible for transmitting and sending the names of all signals.

[0092] Simultaneously, in this step, to ensure that the signal values ​​in the generated test signals are constrained within a reasonable parameter range, thereby further improving the realism of the test signals, a signal definition file corresponding to the vehicle parameters and signal source, configured in the cloud platform, will be obtained. This signal definition file refers to a standardized configuration file, such as a DBC file, that defines the value range, data format, and physical meaning of signal fields.

[0093] Accordingly, the signal definition file corresponding to the vehicle parameters and signal sources will include the signal value range corresponding to each signal keyword in the signal list.

[0094] S1022. Filter vehicle identifiers that match the vehicle parameters from the vehicle information table.

[0095] The vehicle information sheet includes information about vehicles managed by the cloud platform.

[0096] In this step, since the actual signal reporting scenario requires the reported full signal to include the vehicle identifier to clarify the source of the signal, in order to further improve the realism of the simulated test signal, the target vehicle with the model and OTA version that meet the target test scenario will be selected from the vehicle information table, and the identifier of any target vehicle will be obtained.

[0097] Among them, the vehicle identifier refers to the unique identifier of a vehicle, such as the vehicle identification number (VIN).

[0098] S1023. Based on the signal list, signal definition file, target signal keyword, target signal alarm range, and vehicle identifier, generate at least one test signal corresponding to the custom alarm rule.

[0099] In this step, based on the signal list, signal definition file, target signal keywords, and target signal alarm range, the rationality and standardization of the signal values ​​of each signal keyword in the signal list are constrained. The vehicle identifier and the signal values ​​of each signal keyword are then encapsulated together to form a test signal, generating a test signal corresponding to the custom alarm rule. By changing the signal values ​​of each signal keyword under this principle, multiple test signals can be obtained.

[0100] In one possible implementation, this step can be achieved using steps 3.1 to 3.3 as follows:

[0101] Step 3.1: Obtain at least one initial full signal by determining the signal value of each signal keyword in the signal list according to the signal definition file.

[0102] In this step, the signal value of each signal keyword in the signal list is determined based on the signal value range corresponding to each signal keyword indicated in the signal definition file, resulting in an initial full signal. By changing the signal value of each signal keyword under the guidance of this principle, multiple initial full signals can be obtained.

[0103] As a specific example, this step can be implemented using steps 3.1.1 and 3.1.2 as follows:

[0104] Step 3.1.1: For each signal keyword in the signal list, generate at least one random number within the signal value range corresponding to the signal keyword in the signal definition file using a random function.

[0105] In this step, each signal keyword is traversed sequentially according to the contents of the signal list. The range of legal signal values ​​corresponding to the signal keyword in the signal definition file is used as the unique boundary. At least one random number is generated for each signal keyword within this boundary using a random function.

[0106] Step 3.1.2: Obtain at least one initial full signal by assigning a value to the signal value of each signal keyword in the signal list according to at least one random number corresponding to each signal keyword.

[0107] In this step, for each signal keyword, a value is extracted from at least one random number corresponding to the signal keyword to obtain at least one set of random data. Each set of random data includes a value extracted for each signal keyword. For any set of random data, each value in the random data is used as the signal value of its corresponding signal keyword to obtain an initial full signal containing all signal keywords and corresponding compliant initial values. By iterating through each set of random data and performing this operation, at least one initial full signal can be obtained.

[0108] Steps 3.1.1 to 3.1.2 described above involve iterating through each signal keyword in the signal list, using the legal value range of the corresponding signal keyword in the signal definition file as the boundary, and automatically generating at least one random number for each signal keyword using a random function. The random number is then matched and assigned to the corresponding signal keyword one by one. The use of the random function enables the rapid batch generation of the initial full set of signals while ensuring that all signal values ​​strictly comply with the standardized value range requirements of the signal definition file, thereby improving the efficiency of test signal generation.

[0109] Step 3.2: For each initial full signal, adjust the signal value corresponding to the target signal keyword in the initial full signal according to the test purpose and the target signal alarm range to obtain a single full signal corresponding to the initial full signal.

[0110] It should be understood that, depending on the intent of the alarm test on the cloud platform, it is necessary to generate abnormal test signals that will trigger alarms and normal test signals that will not trigger alarms. For example, if a false alarm rate test is required, a normal test signal needs to be generated; if a false negative rate test is required, an abnormal test signal needs to be generated.

[0111] Therefore, in this step, for each initial full signal, the signal value corresponding to the target signal keyword in the initial full signal needs to be adjusted according to the user's testing purpose, so as to obtain a single full signal corresponding to that initial full signal, so that the single full signal meets the testing purpose.

[0112] The test objectives include expecting the test signal to trigger an alarm on the cloud platform and expecting the test signal not to trigger an alarm on the cloud platform.

[0113] In detail, if the test objective is to expect the test signal to trigger an alarm on the cloud platform, the signal value corresponding to the target signal keyword in the initial full signal will be adjusted to any value within the target signal alarm range; if the test objective is to expect the test signal not to trigger an alarm on the cloud platform, the signal value corresponding to the target signal keyword in the initial full signal will be adjusted to any value outside the target signal alarm range.

[0114] For example, regarding the custom alarm rule 1 in the aforementioned embodiment, if the test objective is to expect the test signal to trigger an alarm on the cloud platform, the signal value of the battery temperature signal in the initial full signal can be adjusted to any value greater than 60°C (e.g., 80°C); if the test objective is to expect the test signal not to trigger an alarm on the cloud platform, the signal value corresponding to the battery temperature signal in the initial full signal can be adjusted to any value less than or equal to 60°C (e.g., 40°C).

[0115] Step 3.3: Combine the vehicle identifier with each individual full signal to obtain at least one test signal.

[0116] In this step, for each individual full signal, the individual full signal is combined and associated with the vehicle identifier to obtain the test signal with clear vehicle attributes corresponding to the full signal.

[0117] It should be understood that this step, by assigning a unique vehicle identity anchor to the test signal, allows the test signal to be accurately identified and attributed to the corresponding vehicle by the cloud platform. At the same time, it adapts to different scenario requirements such as single-line testing and multi-model comparison testing, providing a standardized test carrier with complete attributes for subsequent targeted cloud alarm testing.

[0118] The method provided in steps 3.1 to 3.3 of this implementation obtains an initial full signal by determining the signal value of each signal keyword in the signal list according to the signal definition file, adjusting the signal value of the target signal keyword in combination with the test purpose and the target signal alarm range to obtain a single full signal, and then combining the vehicle identifier with the single full signal. This allows for the simulation of a specified scenario, and the test signal can accurately cover the two test purposes of "triggering a cloud platform alarm" and "not triggering a cloud platform alarm", significantly improving the test coverage. It can also simultaneously achieve a one-to-one correspondence between the test signal and the vehicle identifier, further improving the realism of the test signal.

[0119] The alarm testing method for the vehicle-to-everything (V2X) cloud platform provided in this application obtains the corresponding signal list and signal definition file based on vehicle parameters and signal sources, and clarifies the signal value range of each signal keyword; accurately filters out vehicle identifiers that match the vehicle parameters from the vehicle information table containing vehicle information managed by the cloud platform; and then generates at least one test signal corresponding to the custom alarm rule by combining the signal list, signal definition file, target signal keywords, target signal alarm range, and vehicle identifier. This enables precise matching of test signals with target test scenarios, ensuring the relevance and effectiveness of the test scenarios.

[0120] Furthermore, Figure 3 This is a flowchart illustrating an alarm testing method for a vehicle-to-everything (V2X) cloud platform provided in Embodiment 3 of this application. Figure 3 As shown, based on the above embodiments, in the method provided by this application embodiment, the signal parameters obtained in step S101 also include the signal reporting period and reporting duration. Accordingly, this embodiment aims to introduce a specific implementation of the aforementioned step S103, including:

[0121] S1031. Generate a test signal sequence based on at least one test signal.

[0122] It should be understood that in practical applications, users can also define the signal reporting duration and signal reporting cycle in the target scenario to further improve the realism of the simulated reported signals and to test the stability and response speed of the cloud alarm function. The reporting duration refers to the duration of signal reporting.

[0123] In this step, a target test signal can be selected from at least one test signal, and a test signal sequence can be generated based solely on that test signal, wherein all test signals included in the test signal sequence are target test signals; or, two or more test signals can be selected from the at least one test signal, and the test signals can be randomly combined to generate a test signal sequence to simulate the unstable fluctuation characteristics of data during the actual signal reporting process.

[0124] S1032. According to the reporting cycle and reporting duration, report the test signal sequence to the cloud platform and collect the alarm results from the cloud platform.

[0125] In this step, one test signal from the test signal sequence will be reported to the cloud platform in each reporting cycle within the reporting time. After the reporting time ends, alarm results will be collected on the cloud platform. The alarm results include alarms that triggered the custom alarm rule and alarms that did not trigger the custom alarm rule.

[0126] In one possible implementation, this step can be achieved using steps 2.1 to 2.2 as follows:

[0127] Step 2.1: Set a timer according to the reporting duration and start the countdown.

[0128] In this step, the timer duration is set to be the same as the reporting duration, and the countdown begins.

[0129] Step 2.2: During the countdown, report each test signal in the test signal sequence to the cloud platform in sequence according to the reporting cycle.

[0130] In this step, after the countdown begins, the first test signal in the test signal sequence will be reported to the cloud platform at the beginning of the first reporting cycle, and the process will wait for the end of the first reporting cycle. At the beginning of the next reporting cycle, the next test signal in the test signal sequence will be reported to the cloud platform, and the process will wait for the end of that reporting cycle. This process will continue until the countdown ends.

[0131] The method provided in this implementation achieves precise timing control of test signal sequence reporting by setting a timer that precisely matches the reporting duration. This ensures both the timeliness and accuracy of test signal transmission and improves the automation and stability of the entire testing process.

[0132] In addition, in practical applications, multiple test signal sequences can be sent to the cloud platform simultaneously to simulate high-concurrency vehicle signal data reporting scenarios, thereby further verifying the reliability of the cloud platform's alarm function.

[0133] The vehicle-to-everything (V2X) cloud platform alarm testing method provided in this application accurately reports the generated test signal sequence to the cloud platform according to a preset reporting cycle and duration, effectively simulating real-world signal reporting frequency scenarios. This method also incorporates real-time acquisition of alarm results from the cloud platform, completely recreating the entire process of signal transmission, platform response, and result feedback in real-world scenarios. This provides accurate data support for verifying the reliability of the platform's alarm function, significantly improving the authenticity and reference value of the test results, and providing technical support for the high-quality advancement of V2X platform software development and iteration.

[0134] Figure 4 This is a schematic diagram of the structure of an alarm testing device for a vehicle networking cloud platform provided in Embodiment 4 of this application, as shown below. Figure 4 As shown, the alarm testing device 20 for the vehicle network cloud platform provided in this embodiment includes:

[0135] The determination module 201 is used to determine the vehicle parameters and signal parameters of the target test scenario based on the custom alarm rules of the cloud platform; the vehicle parameters include the vehicle model and OTA version; the signal parameters include the signal source, the target signal keyword, and the target signal alarm range.

[0136] The generation module 202 is used to generate at least one test signal corresponding to a custom alarm rule based on vehicle parameters and signal parameters.

[0137] Test module 203 is used to perform alarm tests on the cloud platform using at least one test signal.

[0138] In one possible implementation, the generation module 202 includes:

[0139] The acquisition unit is used to acquire a signal list and a signal definition file corresponding to vehicle parameters and signal sources; the signal definition file includes the signal value range corresponding to each signal keyword in the signal list.

[0140] The filtering unit is used to filter vehicle identifiers that match the vehicle parameters from the vehicle information table; the vehicle information table includes information about vehicles managed by the cloud platform.

[0141] The first generation unit is used to generate at least one test signal corresponding to a custom alarm rule based on the signal list, signal definition file, target signal keyword, target signal alarm range, and vehicle identifier.

[0142] In one possible implementation, the first generating unit includes:

[0143] The acquisition subunit is used to acquire at least one initial full signal by determining the signal value of each signal keyword in the signal list according to the signal definition file;

[0144] The adjustment subunit is used to adjust the signal value corresponding to the target signal keyword in the initial full signal according to the test purpose and the target signal alarm range for each initial full signal, so as to obtain a single full signal corresponding to the initial full signal.

[0145] The combination subunit is used to combine the vehicle identifier with each individual full signal to obtain at least one test signal;

[0146] The test objectives include expecting the test signal to trigger an alarm on the cloud platform and expecting the test signal not to trigger an alarm on the cloud platform.

[0147] In one possible implementation, the adjustment subunit is specifically used for:

[0148] If the purpose of the test is to expect the test signal to trigger an alarm on the cloud platform, then the signal value corresponding to the target signal keyword in the initial full signal will be adjusted to any value within the target signal alarm range.

[0149] If the test objective is to prevent the test signal from triggering an alarm on the cloud platform, then the signal value corresponding to the target signal keyword in the initial full signal will be adjusted to any value outside the target signal alarm range.

[0150] In one possible implementation, the generating unit is specifically used for:

[0151] For each signal keyword in the signal list, at least one random number is generated within the signal value range corresponding to the signal keyword in the signal definition file using a random function.

[0152] At least one initial full signal is obtained by assigning a value to the signal value of each signal keyword in the signal list according to at least one random number corresponding to each signal keyword.

[0153] In one possible implementation, the test module 203 includes:

[0154] The second generation unit is used to generate a test signal sequence based on at least one test signal;

[0155] The reporting unit is used to report the test signal sequence to the cloud platform according to the reporting cycle and reporting duration, and to collect the alarm results from the cloud platform.

[0156] In one possible implementation, the reporting unit is specifically used for:

[0157] Set a timer based on the reporting duration and start the countdown;

[0158] During the countdown, each test signal in the test signal sequence is reported to the cloud platform in sequence according to the reporting cycle.

[0159] The alarm testing device 20 of the vehicle network cloud platform provided in this embodiment can execute the method provided in the above method embodiment. Its implementation principle and technical effect are similar, and will not be described in detail here.

[0160] Figure 5 A schematic diagram of the structure of the computer device provided in this application. Figure 5 As shown, the computer device 30 provided in this embodiment includes at least one processor 301 and a memory 302. Optionally, the device 30 further includes a communication component 303. The processor 301, memory 302, and communication component 303 are connected via a bus 304.

[0161] In a specific implementation, at least one processor 301 executes computer execution instructions stored in memory 302, causing at least one processor 301 to perform the above-described method.

[0162] The specific implementation process of processor 301 can be found in the above method embodiments, and its implementation principle and technical effect are similar. It will not be repeated here.

[0163] In the above embodiments, it should be understood that the processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), etc. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in this invention can be directly implemented by a hardware processor, or implemented by a combination of hardware and software modules within the processor.

[0164] The memory may include read-only memory and random access memory. The memory may be volatile or non-volatile, or may include both. Non-volatile memory may include read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. Volatile memory may include random access memory (RAM), which serves as an external cache. Many forms of RAM are available by way of example, but not limitation. Examples include Static Random Access Memory (SRAM), Dynamic Random Access Memory (DRAM), Synchronous DRAM (SDRAM), Double Data Rate SDRAM (DDR SDRAM), Enhanced Synchronous DRAM (ESDRAM), Sync Link DRAM (SLDRAM), and Direct Rambus RAM (DR RAM).

[0165] The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of illustration, the buses shown in the accompanying drawings are not limited to a single bus or a single type of bus.

[0166] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the above-described method.

[0167] This application also provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, implement the above-described method.

[0168] The aforementioned readable storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as SRAM, EEPROM, EPROM, PROM, ROM, magnetic storage, flash memory, magnetic disk, or optical disk. The readable storage medium can be any available medium accessible to a general-purpose or special-purpose computer.

[0169] An exemplary readable storage medium is coupled to a processor, enabling the processor to read information from and write information to the readable storage medium. Of course, the readable storage medium can also be a component of the processor. The processor and the readable storage medium can reside within an ASIC. Alternatively, the processor and the readable storage medium can exist as discrete components in a device.

[0170] The division of units is merely a logical functional division; in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be indirect coupling or communication connection through some interfaces, devices, or units, and may be electrical, mechanical, or other forms.

[0171] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0172] In addition, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0173] If a function is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this invention, or the part that contributes to the prior art, or a part 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 instructions 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 of the various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, ROM, RAM, magnetic disks, or optical disks.

[0174] Those skilled in the art will understand that all or part of the steps of the above-described method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When executed, the program performs the steps of the above-described method embodiments; and the aforementioned storage medium includes various media capable of storing program code, such as ROM, RAM, magnetic disks, or optical disks.

[0175] Finally, it should be noted that other embodiments of the invention will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This invention is intended to cover any variations, uses, or adaptations of the invention that follow the general principles of the invention and include common knowledge or customary techniques in the art not disclosed herein, and is not limited to the precise structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of the invention is limited only by the appended claims.

Claims

1. A method for alarm testing on a vehicle-to-everything (V2X) cloud platform, characterized in that, The method includes: Based on the custom alarm rules of the cloud platform, determine the vehicle parameters and signal parameters of the target test scenario; the vehicle parameters include the vehicle model and OTA version; the signal parameters include the signal source, target signal keywords, and target signal alarm range. Based on the vehicle parameters and signal parameters, at least one test signal corresponding to the custom alarm rule is generated. The cloud platform is tested for alarms using at least one of the test signals.

2. The method according to claim 1, characterized in that, The step of generating at least one test signal corresponding to the custom alarm rule based on the vehicle parameters and signal parameters includes: Obtain a signal list and a signal definition file corresponding to the vehicle parameters and the signal source; the signal definition file includes the signal value range corresponding to each signal keyword in the signal list. The vehicle identifiers that match the vehicle parameters are filtered from the vehicle information table; the vehicle information table includes information about vehicles managed by the cloud platform. Based on the signal list, the signal definition file, the target signal keyword, the target signal alarm range, and the vehicle identifier, at least one test signal corresponding to the custom alarm rule is generated.

3. The method according to claim 2, characterized in that, The step of generating at least one test signal corresponding to the custom alarm rule based on the signal list, the signal definition file, the target signal keyword, the target signal alarm range, and the vehicle identifier includes: By determining the signal value of each signal keyword in the signal list according to the signal definition file, at least one initial full signal is obtained; For each initial full signal, the signal value corresponding to the target signal keyword in the initial full signal is adjusted according to the test purpose and the target signal alarm range to obtain a single full signal corresponding to the initial full signal. The vehicle identifier is combined with each individual full signal to obtain the at least one test signal; The test objectives include the expectation that the test signal will trigger an alarm on the cloud platform and the expectation that the test signal will not trigger an alarm on the cloud platform.

4. The method according to claim 3, characterized in that, The step of adjusting the signal value corresponding to the target signal keyword in the initial full signal according to the test objective and the target signal alarm range includes: If the purpose of the test is to expect the test signal to trigger an alarm on the cloud platform, then the signal value corresponding to the target signal keyword in the initial full signal is adjusted to any value within the target signal alarm range. If the purpose of the test is to prevent the test signal from triggering an alarm on the cloud platform, then the signal value corresponding to the target signal keyword in the initial full signal is adjusted to any value outside the target signal alarm range.

5. The method according to claim 3, characterized in that, The step of determining the signal value of each signal keyword in the signal list according to the signal definition file, and obtaining at least one initial full signal, includes: For each signal keyword in the signal list, at least one random number is generated within the signal value range corresponding to the signal keyword in the signal definition file using a random function; The at least one initial full signal is obtained by assigning a value to the signal value of each signal keyword in the signal list according to at least one random number corresponding to each signal keyword.

6. The method according to any one of claims 1 to 5, characterized in that, The signal parameters also include the signal reporting period and reporting duration; the alarm test of the cloud platform using the at least one test signal includes: Generate a test signal sequence based on the at least one test signal; According to the reporting cycle and the reporting duration, the test signal sequence is reported to the cloud platform, and the alarm results of the cloud platform are collected.

7. The method according to claim 6, characterized in that, The step of reporting the test signal sequence to the cloud platform according to the reporting cycle and the reporting duration includes: Set a timer according to the reported duration and start the countdown; During the countdown, each test signal in the test signal sequence is reported to the cloud platform in sequence according to the reporting period.

8. An alarm testing device for a vehicle networking cloud platform, characterized in that, The method includes: The determination module is used to determine the vehicle parameters and signal parameters of the target test scenario based on the custom alarm rules of the cloud platform; the vehicle parameters include the vehicle model and OTA version; the signal parameters include the signal source, the target signal keyword, and the target signal alarm range. The generation module is used to generate at least one test signal corresponding to the custom alarm rule based on the vehicle parameters and signal parameters. The testing module is used to perform alarm tests on the cloud platform using at least one test signal.

9. A computer device, characterized in that, include: Memory, processor; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory, causing the processor to perform the method as described in any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, are used to implement the method as described in any one of claims 1-7.

Images