Cloud response method, device and equipment for OTA test and storage medium

Abstract

The invention discloses a cloud response method and device for OTA testing, equipment and a storage medium. In the scheme, service response configuration and process control configuration are received, the service response configuration defines a corresponding relation between a vehicle end OTA request and cloud response content, and the process control configuration comprises a service final state judgment rule and is used for judging whether an OTA service process reaches a preset stage or not. And receiving a vehicle end OTA request, and generating and returning response content based on the service response configuration. And judging whether the request meets a preset stage achievement condition based on a service final state judgment rule, and if yes, creating a synchronous identification file for indicating that the preset stage of the service process is completed. According to the technical scheme, the process state sensing mechanism is introduced while the vehicle end request is responded, the service progress is actively recognized and fed back in a file mode, the OTA test framework can obtain the progress without analyzing the service message, the test logic complexity is reduced, and the automatic cooperation efficiency is improved.

Description

Technical Field

[0001] This application relates to the field of vehicle testing technology, and in particular to a cloud-based response method, apparatus, device, and storage medium for OTA testing. Background Technology

[0002] In the automated testing of over-the-air (OTA) software systems for vehicles, it is typically necessary to deploy cloud simulation services to mimic the behavior of a real OTA cloud platform, enabling the vehicle to complete interactive verification for various test scenarios. Cloud response, as a core component of the cloud simulation service, directly impacts the efficiency and reliability of the testing process through its response methods and capabilities.

[0003] Existing cloud-based response methods lack the ability to perceive OTA business processes in practical applications. Unable to identify the stages and states of the business process, these methods can only interact through a passive request-response model, unable to proactively provide feedback on the completion status of each stage. Under this model, to know the test progress during OTA testing, it is necessary to deeply analyze the business messages exchanged between the vehicle and the cloud to extract status information for judging process progress. This approach requires the OTA testing framework to handle a large amount of business-level data parsing, increasing the complexity of OTA testing logic and reducing the efficiency of automated collaboration in OTA testing, making it difficult to meet the practical application needs of OTA automated testing. Summary of the Invention

[0004] To address the aforementioned issues, this application provides a cloud-based response method, apparatus, device, and storage medium for OTA testing. The aim is to enable the cloud-based response service to perceive the business process status and proactively provide feedback on process progress, thereby reducing the complexity of OTA testing logic, improving the efficiency of automated collaboration in OTA testing, and ultimately meeting the practical application needs of automated OTA testing.

[0005] The embodiments of this application disclose the following technical solutions: The first aspect of this application provides a cloud-based response method for OTA testing, the method comprising: The system receives service response configuration and process control configuration; the service response configuration is used to define the correspondence between vehicle-side OTA requests and cloud-based response content; the process control configuration is used to define monitoring rules for the OTA service process, and the process control configuration includes service final state judgment rules, which are pre-declared conditions for determining that the OTA service process has reached a preset stage. Receive an OTA request sent by the vehicle terminal, generate a service response content corresponding to the OTA request based on the service response configuration, and return the service response content to the vehicle terminal; Based on the business final state judgment rules in the process control configuration, determine whether the OTA request meets the achievement conditions of the pre-declared OTA business process preset stage; If the OTA request meets the conditions for the completion of a pre-declared preset stage of the OTA business process, a synchronization identifier file is created; the synchronization identifier file is used to indicate that the preset stage of the OTA business process has been completed.

[0006] In an optional implementation, the service response configuration includes the correspondence between request features and response content; the request features are used to characterize the identification elements of the OTA request. The step of generating the service response content corresponding to the OTA request based on the service response configuration includes: Extract the request features from the OTA request; Based on the correspondence between request features and response content in the service response configuration, the response content corresponding to the request feature is determined.

[0007] In an optional implementation, the request features include the API path of the OTA request and / or the vehicle identifier.

[0008] In an optional implementation, the process control configuration further includes a target vehicle identifier list; before determining whether the OTA request meets the pre-declared conditions for the achievement of a preset stage of the OTA business process based on the business final state judgment rules in the process control configuration, the cloud response method for OTA testing further includes: Extract the vehicle identifier from the OTA request; Determine whether the vehicle identifier exists in the target vehicle identifier list; If the vehicle identifier exists in the target vehicle identifier list, the step of determining whether the OTA request meets the pre-declared conditions for the achievement of the preset stage of the OTA business process is executed based on the business final state judgment rule in the process control configuration. If the vehicle identifier does not exist in the target vehicle identifier list, the processing of the OTA request ends.

[0009] In an optional implementation, the business final state determination rule is to determine that the conditions for achieving the preset stage are met when the preset business field in the OTA request takes a preset value. The determination of whether the OTA request meets the pre-declared conditions for achieving a preset stage of the OTA service process, based on the service final state judgment rules in the process control configuration, includes: Extract the preset business fields and their corresponding values ​​from the OTA request; Match the preset business fields and their corresponding values ​​with the business final state judgment rules; If the match is successful, the OTA request is determined to meet the conditions for achieving the pre-declared preset stage of the OTA business process.

[0010] In an optional implementation, the process control configuration further includes data recording rules; the data recording rules include original request recording rules and / or status field recording rules; the original request recording rules are used to define the recording path and recording trigger rules for original request data; the status field recording rules are used to define the recording path and recording trigger rules for status field data. The cloud response method for OTA testing also includes: Based on the data recording rules, the original request data and / or status field data during the OTA test process are written to the log file specified by the corresponding recording path.

[0011] A second aspect of this application provides a cloud-based response device for OTA testing, the device comprising: A configuration receiving module is used to receive service response configuration and process control configuration; the service response configuration is used to define the correspondence between vehicle-side OTA requests and cloud-based response content; the process control configuration is used to define monitoring rules for the OTA service process, and the process control configuration includes service final state judgment rules, which are pre-declared conditions for determining that the OTA service process has reached a preset stage. The request processing module is used to receive OTA requests sent by the vehicle terminal, generate service response content corresponding to the OTA request based on the service response configuration, and return the service response content to the vehicle terminal. The final state judgment module is used to determine whether the OTA request meets the conditions for achieving the preset stage of the pre-declared OTA business process based on the business final state judgment rules in the process control configuration. The file creation module is used to create a synchronization identifier file when the OTA request meets the conditions for the completion of the preset stage of the pre-declared OTA business process; the synchronization identifier file is used to indicate that the preset stage of the OTA business process has been completed.

[0012] In an optional implementation, the service response configuration includes the correspondence between request features and response content; the request features are used to characterize the identification elements of the OTA request. The request processing module is specifically used for: Extract the request features from the OTA request; Based on the correspondence between request features and response content in the service response configuration, the response content corresponding to the request feature is determined.

[0013] A third aspect of this application provides a cloud-based response device for OTA testing, the device comprising: a processor and a memory. The memory is used to store program code and transmit the program code to the processor; The processor is configured to execute, according to the instructions in the program code, the steps of the cloud-based response method for OTA testing described in any implementation of the first aspect.

[0014] A fourth aspect of this application provides a computer-readable storage medium for storing program code for performing the steps of the cloud-based response method for OTA testing described in any implementation of the first aspect.

[0015] Compared with the prior art, this application has the following beneficial effects: In this application's technical solution, the system first receives a service response configuration and a process control configuration. The service response configuration defines the correspondence between vehicle-side OTA requests and cloud-based response content. The process control configuration defines monitoring rules for the OTA service process, including service termination judgment rules, which are pre-declared conditions for determining when the OTA service process reaches a preset stage. Next, the system receives an OTA request from the vehicle, generates a service response content corresponding to the OTA request based on the service response configuration, and returns the service response content to the vehicle. Then, based on the service termination judgment rules in the process control configuration, it determines whether the OTA request meets the pre-declared conditions for achieving the preset stage of the OTA service process. Finally, if the OTA request meets the pre-declared conditions for achieving the preset stage of the OTA service process, a synchronization identifier file is created. The synchronization identifier file indicates that the preset stage of the OTA service process has been completed. As can be seen, the technical solution of this application introduces a process status awareness mechanism while completing the vehicle-side request response, enabling the cloud response service to proactively identify the progress of the business process and provide feedback to the outside world in the form of files. The test progress can be known without the test framework deeply parsing the business messages, thereby reducing the complexity of OTA test logic, improving the automated collaboration efficiency between the test framework and the cloud simulation service, and effectively meeting the practical application needs of OTA automated testing. Attached Figure Description

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

[0017] Figure 1 A flowchart of a cloud-based response method for OTA testing is provided in an embodiment of this application; Figure 2 This is a schematic diagram of a cloud-based response device for OTA testing provided in an embodiment of this application. Detailed Implementation

[0018] As described earlier, the automated testing process for automotive OTA systems typically requires the deployment of cloud simulation services to mimic the behavior of a real OTA cloud platform, enabling the vehicle to complete interactive verifications across various test scenarios. Cloud response, as a core component of the cloud simulation service, directly impacts the efficiency and reliability of the testing process through its response methods and capabilities.

[0019] Existing cloud-based response methods lack the ability to perceive OTA business processes in practical applications. Unable to identify the stages and states of the business process, these methods can only interact through a passive request-response model, unable to proactively provide feedback on the completion status of each stage. Under this model, to know the test progress during OTA testing, it is necessary to deeply analyze the business messages exchanged between the vehicle and the cloud to extract status information for judging process progress. This approach requires the OTA testing framework to handle a large amount of business-level data parsing, increasing the complexity of OTA testing logic and reducing the efficiency of automated collaboration in OTA testing, making it difficult to meet the practical application needs of OTA automated testing.

[0020] To address the aforementioned issues, the inventors have developed a cloud-based response method, apparatus, device, and storage medium for OTA testing.

[0021] First, the system receives a service response configuration and a process control configuration. The service response configuration defines the correspondence between vehicle-side OTA requests and cloud-based response content. The process control configuration defines monitoring rules for the OTA service process, including service termination judgment rules, which are pre-declared conditions for determining when the OTA service process has reached a preset stage. Next, the system receives an OTA request from the vehicle, generates a service response content corresponding to the OTA request based on the service response configuration, and returns the service response content to the vehicle. Then, based on the service termination judgment rules in the process control configuration, it determines whether the OTA request meets the pre-declared conditions for reaching the preset stage of the OTA service process. Finally, if the OTA request meets the pre-declared conditions for reaching the preset stage of the OTA service process, a synchronization identifier file is created. The synchronization identifier file indicates that the preset stage of the OTA service process has been completed. As can be seen, the technical solution of this application introduces a process status awareness mechanism while completing the vehicle-side request response, enabling the cloud response service to proactively identify the progress of the business process and provide feedback to the outside world in the form of files. The test progress can be known without the test framework deeply parsing the business messages, thereby reducing the complexity of OTA test logic, improving the automated collaboration efficiency between the test framework and the cloud simulation service, and effectively meeting the practical application needs of OTA automated testing.

[0022] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of the present application.

[0023] This application provides a cloud-based response method for OTA testing, applied within an OTA automated testing framework. In this framework, the cloud-based response service simulates the behavior of a real OTA center and interacts with the vehicle.

[0024] See Figure 1 This figure is a flowchart of a cloud-based response method for OTA testing provided in an embodiment of this application. Figure 1 As shown, the method includes the following steps: S101, Configuration for receiving service responses and process control.

[0025] In this embodiment, the service response configuration defines the correspondence between vehicle-side OTA requests and cloud-based response content. Vehicle-side OTA requests refer to various HTTP requests initiated by the vehicle to the cloud during the upgrade process, such as querying upgrade packages and reporting installation status. Cloud-based response content refers to the response message returned by the cloud service to the vehicle, which can be a standard success response or a simulated exception response, such as timeout and error codes.

[0026] The process control configuration defines the monitoring rules for the OTA business process, guiding the cloud service on how to detect the progress of the OTA business process and trigger synchronization signals. The OTA business process refers to the complete phase from task issuance, download, installation to completion.

[0027] In this embodiment of the application, the process control configuration includes business final state judgment rules, which are pre-declared conditions used to determine whether the OTA business process has reached a preset stage.

[0028] In one example implementation, the business response configuration can adopt a key-value pair structure of "request characteristics - response content". Request characteristics may include API path, request method, vehicle identifier (VIN), etc.

[0029] In an alternative implementation, to support real-time changes without restarting the cloud response service, the business response configuration is dynamically distributed by the OTA testing framework via a dedicated hot update interface, such as the HTTP API / update_response.

[0030] In one example implementation, the flow control configuration can be loaded as a JSON file, independent of the business response configuration. Its core content may include: record_vin: A list of target vehicle identifiers, defining the vehicles that need to be monitored during this test period.

[0031] touch_request: A declarative rule that defines the final state conditions of a business application and creates a synchronization identifier file when a match is successful.

[0032] record_request and record_state: Data recording rules, specifying the original request or state fields to be saved and their storage paths.

[0033] Below is a JSON example of a process control configuration. This example defines how, for a vehicle with VIN LA02SW00000000179, when the state field value reported by the state / report interface is "Install_Successed", an update_finish file will be created at a specified path:

[0034] This application embodiment separates the configuration of business logic and process awareness logic, enabling cloud-based responses to have high configurability and maintainability. Testers can define complex business simulation behaviors and process monitoring rules without modifying the code.

[0035] S102. Receive the OTA request sent by the vehicle terminal, generate the service response content corresponding to the OTA request based on the service response configuration, and return the service response content to the vehicle terminal.

[0036] In one optional implementation, the business response configuration supports hot updates to dynamically adjust test behavior. The OTA testing framework can call the management interface at any time during test execution to issue new business response configurations. Based on the newly issued business response configurations, existing rules are merged or replaced in real time, thereby simulating changes in server behavior, such as injecting errors or changing response latency, enriching the testing capabilities for abnormal scenarios.

[0037] In one optional implementation, the service response configuration includes a correspondence between request features and response content. The request features are used to characterize the identifying elements of an OTA request.

[0038] The specific methods for generating the business response content corresponding to the OTA request based on the business response configuration include: Step 1: Extract request features from OTA requests.

[0039] In this application embodiment, the request feature refers to information that can uniquely identify or classify the vehicle-side request, such as API path, HTTP method, vehicle identifier in OTA request, etc.

[0040] In one example implementation, when an OTA request arrives from the vehicle, the HTTP message is parsed to extract the URL path and VIN field.

[0041] Step 2: Based on the correspondence between request features and response content in the business response configuration, determine the response content corresponding to the request features.

[0042] In this embodiment of the application, the extracted request features are matched with the request features in the business response configuration. If there is a complete match, the corresponding response content is used as the response message. If there is a partial match, such as only the API path is matched but the VIN is not matched, a default response can be returned or the search can continue according to the preset configuration strategy.

[0043] In one alternative implementation, to enhance matching flexibility, request features include the API path of the OTA request and / or the vehicle identifier. By combining the API path and VIN, fine-grained response control for specific vehicles can be achieved.

[0044] In an alternative implementation, to support precise isolation during parallel testing of multiple vehicles, the service response configuration can also include differentiated responses based on the VIN. For example, for the same API path, different response content can be configured for different VINs, thereby simulating the personalized upgrade process for different vehicles.

[0045] This application embodiment enables cloud services to accurately respond to various testing needs through flexible business response configuration and hot update mechanism, supports dynamic switching of complex scenarios, and improves test coverage and efficiency.

[0046] S103. Based on the business final state judgment rules in the process control configuration, determine whether the OTA request meets the achievement conditions of the pre-declared OTA business process preset stage.

[0047] In this embodiment of the application, when processing the vehicle-side OTA request, not only is a response returned, but the rules in the process control configuration are also used to determine whether the current OTA request indicates that the OTA business process has entered a preset stage, such as successful installation or installation failure.

[0048] In one example implementation, the business finality judgment rules are defined using declarative syntax, such as a `touch_request` array in JSON. Each rule contains: file: The path to create the synchronization identifier file.

[0049] timing: Triggering condition, usually specifying a certain interface, such as state / report, and its internal fields, such as the expected list of values ​​for state.

[0050] When processing each OTA request, the interface identifier and business fields in the OTA request are extracted and matched against all touch_request rules. If the interface and field values ​​of the OTA request match a rule, the conditions for the preset stage are considered met.

[0051] In one optional implementation, to improve the accuracy of the judgment and avoid interference, the process control configuration also includes a target vehicle identifier list. Before processing an OTA request, the vehicle identifier is extracted. Subsequent business finality judgments are only executed if the vehicle identifier exists in the list; otherwise, they are skipped, and only a regular response is performed. This mechanism ensures that the process monitoring of each vehicle does not interfere with each other in a multi-vehicle parallel testing environment.

[0052] Specifically, prior to step S103, a cloud-based response method for OTA testing according to an embodiment of this application further includes: Step 1: Extract the vehicle identifier from the OTA request.

[0053] Step 2: Determine if the vehicle identifier exists in the target vehicle identifier list.

[0054] In this embodiment of the application, if the condition exists, proceed to step 3; if it does not exist, proceed to step 4.

[0055] Step 3: Execute step S103 and subsequent procedures.

[0056] Step 4: End the process monitoring and processing of the OTA request, and only return the business response.

[0057] In an optional implementation, to accurately match the final state of the service, the rule for determining the final state is that if the preset service field in the OTA request takes a preset value, the conditions for achieving the preset stage are met. Step S103 includes: S1031. Extract the preset business fields and their corresponding values ​​from the OTA request.

[0058] In this embodiment of the application, the preset business fields refer to the key fields specified in the process control configuration, such as state and result, and the values ​​of these fields are parsed from the OTA request.

[0059] In one example implementation, for a request to the state / report interface, the OTA request might be {"state":"Install_Successed", "vin":"..."}, from which the value of the state field is extracted.

[0060] S1032. Match the preset business fields and their corresponding values ​​with the business final state judgment rules.

[0061] In this embodiment of the application, the business final state judgment rules are traversed to check whether the preset business fields in the current OTA request match the corresponding fields specified in the business final state judgment rules, and whether the extracted field values ​​match the field values ​​in the business final state judgment rules.

[0062] In one example implementation, the business final state determination rule is as follows: {"state / report": {"key":"state", "value":["Install_Successed"]}}; Compare the current OTA request's interface state / report and field value Install_Successed with this rule to determine if they match.

[0063] S1033. If the match is successful, determine that the OTA request meets the conditions for achieving the pre-declared OTA business process preset stage.

[0064] This application embodiment achieves accurate perception of business status through a field matching mechanism.

[0065] This application embodiment achieves strict isolation of the test context and accurate identification of the business status by introducing vehicle identification filtering and field matching rules, ensuring that the generation of process signals is only for the correct stage of the monitored vehicle.

[0066] S104. If the OTA request meets the conditions for the pre-declared OTA business process preset stage, create a synchronization identifier file.

[0067] In this embodiment of the application, the synchronization identifier file is used to indicate that a preset stage of the OTA business process has been completed.

[0068] In this embodiment, the synchronization identifier file is an empty file; its existence indicates that "a key stage of the test process has been achieved." This file can be physically created at a specified path by calling the operating system interface, serving as a machine-readable binary signal for the test framework or other monitoring programs to perceive.

[0069] In one example implementation, after step S103 determines that the business final state judgment rule is met, an empty file, such as update_finish, is created in the path specified by the rule. The testing framework can monitor changes to this file through polling or an inotify mechanism. Once the file is found to have been created, it can determine that the business process has entered the preset stage, thereby driving subsequent test actions, such as starting the next test step or recording the results.

[0070] In another example implementation, the process control configuration may define multiple business finality judgment rules, corresponding to different stages, such as download complete, installation successful, and installation failed. Different identifier files are created based on the actual OTA request, matching different business finality judgment rules to provide fine-grained process synchronization signals for the testing framework.

[0071] In an optional implementation, the flow control configuration also includes data logging rules. These rules include rules for recording original requests and / or rules for recording status fields, i.e., the `record_request` and `record_state` fields in the example flow control configuration above.

[0072] Among them, the original request record rule is used to define the record path and record triggering rule for the original request data, and the status field record rule is used to define the record path and record triggering rule for the status field data.

[0073] A cloud-based response method for OTA testing, according to an embodiment of this application, further includes: Based on data recording rules, the original request data and / or status field data during the OTA testing process are written to the log file specified by the corresponding recording path.

[0074] In this embodiment of the application, when processing OTA requests, the original request message and / or specific status fields are appended to a designated log file according to data recording rules, providing raw data for post-test verification and analysis. For example, the record_request in the process control configuration can record the request content of the state / report interface to result.txt, and the record_state can record the state field value to state.txt.

[0075] This application embodiment transforms complex business status events into atomic signals that the OTA testing framework can directly consume by creating a synchronization identifier file—a simple and reliable method—achieving efficient decoupling and collaboration with the automated testing framework. The OTA testing framework does not need to parse business messages; it can perceive the progress of the OTA business process simply by verifying the file's existence, simplifying the complexity of automated testing logic.

[0076] This application embodiment introduces a process status awareness mechanism while completing the vehicle-side request response, enabling the cloud response service to proactively identify the progress of the business process and provide feedback externally in the form of files. This eliminates the need for the test framework to deeply parse business messages to know the test progress, thereby reducing the complexity of OTA test logic, improving the automated collaboration efficiency between the test framework and the cloud simulation service, and effectively meeting the practical application needs of OTA automated testing.

[0077] Based on the cloud response method for OTA testing provided in the foregoing embodiments, this application also provides a cloud response device for OTA testing. Figure 2 This is a schematic diagram of a cloud-based response device for OTA testing, provided as an embodiment of this application. Figure 2 As shown, the cloud response device used for OTA testing includes: a configuration receiving module 201, a request processing module 202, a final state judgment module 203, and a file creation module 204.

[0078] The configuration receiving module 201 is used to receive service response configuration and process control configuration. The service response configuration is used to define the correspondence between the vehicle-side OTA request and the cloud response content. The process control configuration is used to define the monitoring rules of the OTA business process. The process control configuration includes the business final state judgment rule, which is a pre-declared condition for determining that the OTA business process has reached a preset stage.

[0079] The request processing module 202 is used to receive OTA requests sent by the vehicle, generate service response content corresponding to the OTA request based on the service response configuration, and return the service response content to the vehicle.

[0080] The final state judgment module 203 is used to determine whether the OTA request meets the pre-declared conditions for the achievement of the preset stage of the OTA business process based on the business final state judgment rules in the process control configuration.

[0081] The file creation module 204 is used to create a synchronization identifier file when the OTA request meets the conditions for the completion of the preset stage of the pre-declared OTA business process; the synchronization identifier file is used to indicate that the preset stage of the OTA business process has been completed.

[0082] In this embodiment, the configuration receiving module 201 receives independent business response configurations and process control configurations. The request processing module 202 dynamically responds to vehicle-side requests based on the business response configurations. The final state judgment module 203 accurately perceives the business process status based on the process control configurations. The file creation module 204 generates a synchronization identifier file when conditions are met. All modules work together to complete the vehicle-side OTA request response, enabling the cloud response service to perceive the business process status and proactively provide feedback on process progress. This reduces the complexity of OTA testing logic, improves the automated collaborative efficiency of OTA testing, and thus meets the practical application needs of OTA automated testing.

[0083] In the optional implementation, the service response configuration includes the correspondence between request features and response content; the request features are used to characterize the identification elements of the OTA request.

[0084] Request processing module 202 is specifically used for: Extract request features from OTA requests.

[0085] Based on the correspondence between request features and response content in the business response configuration, the response content corresponding to the request features is determined.

[0086] In an optional implementation, the request characteristics include the API path of the OTA request and / or the vehicle identifier.

[0087] In the optional implementation, the process control configuration also includes a target vehicle identifier list, and the cloud response device for OTA testing also includes a target judgment module.

[0088] The target determination module is used to extract the vehicle identifier from the OTA request. It determines whether the vehicle identifier exists in the target vehicle identifier list. If the vehicle identifier exists in the target vehicle identifier list, the final state determination module 203, based on the business final state determination rules in the process control configuration, determines whether the OTA request meets the pre-declared conditions for the preset stage of the OTA business process. If the vehicle identifier does not exist in the target vehicle identifier list, the processing of the OTA request ends.

[0089] In the optional implementation, the business final state determination rule is that if the preset business field in the OTA request takes a preset value, the conditions for achieving the preset stage are met. The final state determination module 203 is specifically used for: Extract the preset business fields and their corresponding values ​​from the OTA request. Match the preset business fields and their corresponding values ​​with the business final state judgment rules. If the match is successful, determine that the OTA request meets the conditions for achieving the preset stage of the pre-declared OTA business process.

[0090] In the optional implementation, the process control configuration also includes data recording rules; the data recording rules include original request recording rules and / or status field recording rules; the original request recording rules are used to define the recording path and recording trigger rules for original request data; the status field recording rules are used to define the recording path and recording trigger rules for status field data. The cloud response device for OTA testing also includes a data recording module.

[0091] The data logging module is used to write the raw request data and / or status field data during the OTA testing process to the log file specified by the corresponding logging path, based on data logging rules.

[0092] Furthermore, embodiments of this application also provide a cloud-based response device for OTA testing, the device including a processor and a memory.

[0093] The memory is used to store program code and transmit the program code to the processor; The processor is used to execute the steps of the cloud response method for OTA testing described in any of the above method embodiments according to the instructions in the program code.

[0094] Furthermore, embodiments of this application also provide a computer-readable storage medium storing program code, the program code being used to execute the steps of the cloud response method for OTA testing described in any of the above method embodiments.

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

[0096] The above description is merely one specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A cloud-based response method for OTA testing, characterized in that, include: Configure and control the process for receiving service responses; The service response configuration is used to define the correspondence between vehicle-side OTA requests and cloud-based response content; The process control configuration is used to define the monitoring rules for the OTA business process. The process control configuration includes business final state judgment rules, which are pre-declared conditions for determining that the OTA business process has reached a preset stage. Receive an OTA request sent by the vehicle terminal, generate a service response content corresponding to the OTA request based on the service response configuration, and return the service response content to the vehicle terminal; Based on the business final state judgment rules in the process control configuration, determine whether the OTA request meets the achievement conditions of the pre-declared OTA business process preset stage; If the OTA request meets the conditions for the completion of a pre-declared preset stage of the OTA business process, a synchronization identifier file is created; the synchronization identifier file is used to indicate that the preset stage of the OTA business process has been completed.

2. The method according to claim 1, characterized in that, The service response configuration includes the correspondence between request features and response content; The request features are used to characterize the identification elements of an OTA request; The step of generating the service response content corresponding to the OTA request based on the service response configuration includes: Extract the request features from the OTA request; Based on the correspondence between request features and response content in the service response configuration, the response content corresponding to the request feature is determined.

3. The method according to claim 2, characterized in that, The request characteristics include the API path of the OTA request and / or the vehicle identifier.

4. The method according to claim 1, characterized in that, The process control configuration also includes a target vehicle identifier list; before determining whether the OTA request meets the pre-declared conditions for the achievement of a preset stage of the OTA service process based on the service final state judgment rules in the process control configuration, the method further includes: Extract the vehicle identifier from the OTA request; Determine whether the vehicle identifier exists in the target vehicle identifier list; If the vehicle identifier exists in the target vehicle identifier list, the step of determining whether the OTA request meets the pre-declared conditions for the achievement of the preset stage of the OTA business process is executed based on the business final state judgment rule in the process control configuration. If the vehicle identifier does not exist in the target vehicle identifier list, the processing of the OTA request ends.

5. The method according to claim 1, characterized in that, The business final state determination rule is that if the preset business field in the OTA request takes a preset value, the conditions for achieving the preset stage are met. The determination of whether the OTA request meets the pre-declared conditions for achieving a preset stage of the OTA service process, based on the service final state judgment rules in the process control configuration, includes: Extract the preset business fields and their corresponding values ​​from the OTA request; Match the preset business fields and their corresponding values ​​with the business final state judgment rules; If the match is successful, the OTA request is determined to meet the conditions for achieving the pre-declared preset stage of the OTA business process.

6. The method according to claim 1, characterized in that, The process control configuration also includes data recording rules; the data recording rules include original request recording rules and / or status field recording rules; the original request recording rules are used to define the recording path and recording trigger rules for original request data; The status field recording rules are used to define the recording path and recording trigger rules for status field data. The method further includes: Based on the data recording rules, the original request data and / or status field data during the OTA test process are written to the log file specified by the corresponding recording path.

7. A cloud-based response device for OTA testing, characterized in that, include: Configure the receiving module to receive service response configuration and process control configuration; The service response configuration is used to define the correspondence between vehicle-side OTA requests and cloud-based response content; The process control configuration is used to define the monitoring rules for the OTA business process. The process control configuration includes business final state judgment rules, which are pre-declared conditions for determining that the OTA business process has reached a preset stage. The request processing module is used to receive OTA requests sent by the vehicle terminal, generate service response content corresponding to the OTA request based on the service response configuration, and return the service response content to the vehicle terminal. The final state judgment module is used to determine whether the OTA request meets the conditions for achieving the preset stage of the pre-declared OTA business process based on the business final state judgment rules in the process control configuration. The file creation module is used to create a synchronization identifier file when the OTA request meets the conditions for the completion of the preset stage of the pre-declared OTA business process; the synchronization identifier file is used to indicate that the preset stage of the OTA business process has been completed.

8. The apparatus according to claim 7, characterized in that, The service response configuration includes the correspondence between request features and response content; the request features are used to characterize the identification elements of OTA requests; The request processing module is specifically used for: Extract the request features from the OTA request; Based on the correspondence between request features and response content in the service response configuration, the response content corresponding to the request feature is determined.

9. A cloud-based response device for OTA testing, characterized in that, include: Processor and memory: The memory is used to store program code and transmit the program code to the processor; The processor is configured to execute the steps of the cloud response method for OTA testing as described in any one of claims 1 to 6 according to the instructions in the program code.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium is used to store program code for performing the steps of the cloud response method for OTA testing as described in any one of claims 1 to 6.

Images