Vehicle wake-up test method based on mobile terminal and related equipment

Abstract

The invention discloses a vehicle wake-up test method based on a mobile terminal and related equipment, and relates to the technical field of vehicle testing, and the method comprises the steps: obtaining an execution result of a target vehicle for an unlocking instruction; if the execution result is that unlocking succeeds, a door opening simulation trigger signal is injected into a vehicle-mounted bus of the target vehicle; acquiring state response data fed back by a plurality of vehicle domains in the target vehicle to the simulation door opening trigger signal; and determining a whole vehicle wake-up test result of the target vehicle based on the state response data. On the premise of confirming that the vehicle is remotely unlocked successfully, the vehicle wake-up result is judged by injecting the simulation door opening trigger signal into the vehicle-mounted bus and integrating the state responses of the multiple vehicle domains, and the vehicle wake-up test which is controllable in wake-up trigger and comprehensive and reliable in judgment basis can be achieved.

Description

Technical Field

[0001] This application relates to the field of vehicle testing technology, and more specifically, to a vehicle wake-up testing method and related equipment based on a mobile terminal. Background Technology

[0002] With the rapid development of vehicle networking technology and smart terminals, remote vehicle control via mobile terminals has become a crucial function of intelligent vehicles. Remote unlocking, door opening, and vehicle wake-up are widely used in daily user operations and vehicle function verification. Testing and verifying vehicle sleep and wake-up states, and accurately evaluating the vehicle's wake-up behavior triggered by remote operations, is of great significance for ensuring vehicle functional reliability and user experience.

[0003] In related technologies, vehicle wake-up testing typically relies on mobile terminals directly sending unlock or door opening commands. The wake-up result is determined by observing external phenomena such as whether the vehicle's screen lights up, powers on, or responds to control commands. However, this type of testing is highly dependent on the stability of the network communication environment and remote control link. The timing and process of wake-up triggering are difficult to control precisely, and test results are easily affected by uncertainties such as network latency and command loss, resulting in poor test repeatability and stability. In other words, related technologies suffer from insufficient controllability of the triggering method during vehicle wake-up testing, leading to poor repeatability and low consistency of test results, making them unreliable as a basis for vehicle performance evaluation and comparative analysis. Summary of the Invention

[0004] The summary section of this application introduces a series of simplified concepts, which will be further explained in detail in the detailed description section. The summary section of this application is not intended to limit the key features and essential technical features of the claimed technical solution, nor is it intended to determine the scope of protection of the claimed technical solution.

[0005] The vehicle wake-up test method and related equipment based on mobile terminals provided in this application can determine the vehicle wake-up result by injecting a simulated door opening trigger signal into the vehicle bus and integrating the status responses of multiple vehicle domains, provided that the vehicle has been successfully unlocked remotely. This enables vehicle wake-up testing with controllable wake-up triggering and comprehensive and reliable judgment criteria.

[0006] In a first aspect, this application provides a vehicle wake-up testing method based on a mobile terminal, applied to a test terminal, comprising: acquiring the execution result of a target vehicle in response to an unlocking command, wherein the unlocking command is a command remotely sent by the mobile terminal to the target vehicle; if the execution result is successful unlocking, injecting a simulated door opening trigger signal into the vehicle bus of the target vehicle; acquiring status response data from multiple vehicle domains in the target vehicle in response to the simulated door opening trigger signal; and determining the whole-vehicle wake-up test result of the target vehicle based on the status response data.

[0007] In some implementations, obtaining the execution result of the target vehicle in response to the unlocking command includes: calling a preset application interface of the mobile terminal to remotely send the unlocking command to the target vehicle; obtaining the response message returned by the target vehicle to the preset application interface; and parsing the status code field in the response message to determine the execution result.

[0008] In some implementations, if the execution result is successful unlocking, injecting a simulated door opening trigger signal into the vehicle bus of the target vehicle includes: determining the authorization start time based on a first timestamp carried in the response message and a second timestamp of the response message received by the preset application interface; determining a signal injection time window based on the authorization start time and a preset authorization validity period; and injecting the simulated door opening trigger signal into the vehicle bus through the bus interface within the signal injection time window.

[0009] In some embodiments, the simulated door opening trigger signal includes a first message indicating that remote authorization is effective and a second message indicating that the target door is open; before injecting the simulated door opening trigger signal into the vehicle bus through the bus interface, the method further includes: obtaining signal configuration parameters corresponding to the vehicle model identifier of the target vehicle, wherein the signal configuration parameters include a first definition rule corresponding to the first message and a second definition rule corresponding to the second message; generating the first message and the second message conforming to the vehicle model identifier based on the first definition rule and the second definition rule; injecting the simulated door opening trigger signal into the vehicle bus through the bus interface includes: sequentially injecting the first message and the second message into the vehicle bus through the bus interface.

[0010] In some implementations, the plurality of vehicle domains includes a power domain, an in-vehicle infotainment domain, and a body domain; acquiring the status response data fed back by the plurality of vehicle domains in the target vehicle to the simulated door opening trigger signal includes: starting a signal monitoring time window of a preset duration after injecting the simulated door opening trigger signal; within the signal monitoring time window, acquiring a first monitoring data stream, a second monitoring data stream, and a third monitoring data stream in parallel through a bus interface, wherein the first monitoring data stream contains parameters characterizing the operating status of the power domain, the second monitoring data stream contains parameters characterizing the operating status of the in-vehicle infotainment domain, and the third monitoring data stream contains parameters characterizing the operating status of the body domain; and using the first monitoring data stream, the second monitoring data stream, and the third monitoring data stream together as the status response data.

[0011] In some implementations, determining the vehicle wake-up test result of the target vehicle based on the state response data includes: determining whether the power domain, the vehicle infotainment domain, and the body domain meet their respective wake-up conditions based on the first monitoring data stream, the second monitoring data stream, and the third monitoring data stream; if the power domain, the vehicle infotainment domain, and the body domain all meet their respective wake-up conditions, then the vehicle wake-up test result is determined to be a successful wake-up; otherwise, the vehicle wake-up test result is determined to be a failed wake-up.

[0012] In some embodiments, the method further includes: if the vehicle wake-up test result is determined to be a wake-up failure, then injecting a rollback control signal into the vehicle bus through the bus interface, wherein the rollback control signal includes a third message for restoring the state of the target door to closed, and a fourth message for indicating remote authorization revocation.

[0013] Secondly, this application also provides a test terminal, comprising: a result acquisition unit, configured to acquire the execution result of a target vehicle in response to an unlocking command, wherein the unlocking command is a command remotely sent by a mobile terminal to the target vehicle; a signal injection unit, configured to inject a simulated door opening trigger signal into the vehicle bus of the target vehicle if the execution result is successful unlocking; a feedback acquisition unit, configured to acquire status response data fed back by multiple vehicle domains in the target vehicle in response to the simulated door opening trigger signal; and a result determination unit, configured to determine the vehicle wake-up test result of the target vehicle based on the status response data.

[0014] Thirdly, this application also provides an electronic device, including: a memory and a processor, wherein the processor is configured to execute a computer program stored in the memory to implement the steps of the vehicle wake-up test method based on a mobile terminal as described in the first aspect.

[0015] Fourthly, this application also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps of the vehicle wake-up test method based on a mobile terminal as described in the first aspect.

[0016] Fifthly, this application also provides a computer program product, including a computer program or computer executable instructions, wherein when the computer program or computer executable instructions are executed by a processor, the steps of the vehicle wake-up test method based on a mobile terminal provided in the embodiments of this application are implemented.

[0017] In summary, this application obtains the execution result of the unlocking command remotely sent by the mobile terminal to the target vehicle, and performs subsequent operations only after confirming successful unlocking. This ensures that the vehicle wake-up test is based on the premise that the vehicle has already been unlocked, guaranteeing that the test process conforms to the vehicle's existing remote unlocking logic and effectively reflecting the vehicle's wake-up state in actual usage scenarios. Upon successful unlocking, the test terminal injects a simulated door opening trigger signal into the target vehicle's onboard bus to trigger vehicle wake-up. Compared to relying entirely on the mobile terminal to send door opening commands, this method allows the wake-up trigger action to be controlled by the test side, improving the controllability of the wake-up trigger timing and conditions. By obtaining the status response data from multiple vehicle domains in response to the simulated door opening trigger signal, the judgment of the vehicle's wake-up state no longer depends on a single module or phenomenon, but is based on a comprehensive analysis of feedback from multiple vehicle domains, improving the comprehensiveness and reliability of the wake-up test results. Furthermore, determining the vehicle wake-up test results based on the obtained status response data from multiple vehicle domains transforms the entire vehicle wake-up process into a clear test conclusion, making the test results verifiable and consistent, facilitating subsequent test analysis and verification. In summary, the vehicle wake-up test method based on mobile terminals provided in this application, under the premise of confirming successful remote unlocking of the vehicle, determines the vehicle wake-up result by injecting a simulated door opening trigger signal into the vehicle bus and integrating the state responses of multiple vehicle domains. This enables vehicle wake-up testing with controllable wake-up triggering and comprehensive and reliable judgment criteria. Attached Figure Description

[0018] Various other advantages and benefits will become apparent to those skilled in the art upon reading the following detailed description of preferred embodiments. The accompanying drawings are for illustrative purposes only and are not intended to limit this specification. Furthermore, the same reference numerals denote the same parts throughout the drawings. In the drawings: Figure 1 A flowchart illustrating a vehicle wake-up test method based on a mobile terminal, provided in an embodiment of this application; Figure 2 A schematic diagram of the composition structure of a test terminal provided in an embodiment of this application; Figure 3 This is a schematic diagram of the composition structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0019] The terms used in the specification, claims, and drawings of this application, such as "first," "second," "third," "fourth," etc. (if any), are used to distinguish similar objects and not to describe a specific order or sequence. Therefore, it is to be understood that these terms can be used interchangeably where appropriate, allowing the described embodiments to be used in different orders, unless specifically required by the illustrations or description. Furthermore, the terms "is" and "has," and any variations thereof, are intended to cover, non-exclusively, all possible constituent elements. For example, a process, method, system, product, or apparatus comprising several steps or units is not necessarily limited to the steps or units explicitly listed, but may also include other steps or units not explicitly listed, or steps or units inherent to the process, method, product, or apparatus.

[0020] In this application, a "module" or "unit" refers to a computer program or part of a computer program that has a specific function and works in conjunction with other related parts to achieve a predetermined goal. These modules or units can be implemented by software, hardware (e.g., processing circuitry or memory), or a combination of both. One or more processors or memories can implement one or more modules or units. Furthermore, each module or unit can also be part of a larger module or unit.

[0021] The technical solutions of this application will be described in detail below with reference to the accompanying drawings of the embodiments. It should be noted that the described embodiments are only a part of this application, and not all embodiments. In the following description, the "some embodiments" mentioned are only a subset of all possible embodiments, which may be the same or different subsets, and different embodiments can be combined with each other without conflict.

[0022] Figure 1 This is a schematic flowchart illustrating a vehicle wake-up testing method based on a mobile terminal, provided in an embodiment of this application. For example, see [link to example]. Figure 1 The vehicle wake-up test method based on a mobile terminal provided in this application embodiment, applied to a test terminal, may include the following steps 101 to 104: Step 101: Obtain the execution result of the target vehicle in response to the unlock command.

[0023] The unlock command is a command sent remotely from the mobile terminal to the target vehicle.

[0024] In some examples, the test terminal is a control device used to execute the vehicle wake-up test method of this application, which has the functions of initiating the test process, interacting with the mobile terminal, receiving relevant data, and advancing the test steps; a device with data processing capabilities, a communication interface, and the ability to deploy test control programs can be selected as the test terminal. The device needs to support the establishment of a stable data interaction link with the mobile terminal and the target vehicle; for example, the test terminal can be an industrial personal computer (IPC), on which a customized vehicle wake-up test control program is installed, and the execution and data flow of each test link are coordinated through the program.

[0025] The target vehicle is the specific vehicle to be tested for vehicle wake-up performance. The target vehicle must be capable of receiving remote unlock commands, responding to bus signals, and providing operational status feedback, and must be in an initial state that meets the test requirements. A mass-produced model or test prototype can be selected to verify the wake-up performance, ensuring that the vehicle's core components, such as the remote communication module, anti-theft authorization module, and body control module, are functioning correctly and meet the hardware requirements for test execution. The mobile terminal is a portable smart device with remote vehicle control capabilities, used to send unlock commands to the target vehicle, serving as the execution carrier for remote authorization. The mobile terminal can be a smart device that supports the installation of a vehicle remote control application (App), and must have mobile communication network access capabilities to communicate with the cloud service platform. The unlock command is a control command used to request the target vehicle to unlock its anti-theft lock status. It is a core pre-requisite command for initiating the vehicle wake-up test and includes verification content such as vehicle identification and user authorization information to ensure the legality and uniqueness of the command. The unlock command can be generated by the vehicle remote control app on the mobile terminal. Specifically, the test terminal can trigger the app's function module on the mobile terminal to generate the unlock command according to the preset command format and protocol. For example, the unlock command may include control commands for the target vehicle identification number (VIN) and user account authorization token. The command format conforms to the communication protocol specifications agreed upon between the cloud service platform and the vehicle. The transmission of unlocking commands must be completed through a remote communication link that is not directly connected, rather than through direct point-to-point communication between the mobile terminal and the target vehicle. This transmission link needs to be relayed and verified by the cloud service platform, which conforms to the remote control logic in mass production scenarios. It can rely on the transmission channel built by the mobile communication network (MCN) and the cloud service platform. The mobile terminal sends the unlocking command to the cloud service platform. After the platform verifies the command, it forwards it to the target vehicle to complete the transmission of the remote command. For example, the mobile terminal connects to a cloud service platform through the 5th generation mobile communication technology (5G) network. The cloud service platform verifies the vehicle identifier and authorization token in the unlocking command. After confirming its legality, it forwards the command to the body control module (BCM) of the target vehicle through the vehicle network terminal (T-Box).The execution result is the final status feedback generated by the target vehicle after receiving the unlock command and performing the unlock operation. It is the key basis for determining whether the conditions for subsequent test execution are met, and can include two core statuses: unlock success and unlock failure. After the target vehicle performs the unlock operation, it can feed back the operation status to the cloud service platform through the vehicle network terminal. The cloud service platform then synchronizes the status to the remote control App on the mobile terminal. The test terminal obtains this status information through interaction with the mobile terminal, thus obtaining the execution result. For example, after the target vehicle's body control module successfully unlocks the anti-theft lock, it feeds back the status information "unlock successful". This status information is transmitted to the mobile terminal App via the vehicle network terminal and the cloud service platform. The test terminal reads this status information from the App, which is the execution result of this unlock command. If the vehicle fails to unlock due to invalid authorization, network interruption, or other reasons, the execution result "unlock failure" is fed back.

[0026] For example, before the test, the test terminal and the mobile terminal establish a communication connection via a wireless local area network to ensure real-time data interaction. Simultaneously, the target vehicle is parked in a test area with stable communication signals, and test preparations such as battery power-on and remote communication module activation are completed. The test terminal sends a command trigger signal to the mobile terminal via a preset communication protocol. The vehicle remote control app on the mobile terminal responds to the signal, generates an unlocking command containing the target vehicle identification code and user authorization token according to a preset format, and sends it to a cloud service platform via a 5G mobile communication network. The cloud service platform verifies the legality of the unlocking command. After confirming that the vehicle identification and authorization information match, it forwards the command to the vehicle's connected vehicle terminal. The connected vehicle terminal transmits the command to the body control module, which executes the unlocking operation and generates an execution result. This execution result is fed back along the original transmission link to the remote control app on the mobile terminal, and the test terminal then obtains the execution result from the mobile terminal.

[0027] By implementing step 101, the execution result of the target vehicle in response to the unlocking command sent remotely by the mobile terminal can be obtained, which can clarify whether the vehicle has completed the unlocking operation. This ensures that the subsequent wake-up test is based on the vehicle being in a legal unlocked state, thereby ensuring that the test process conforms to the vehicle's existing remote unlocking logic and is conducive to reflecting the vehicle's status in actual use scenarios.

[0028] Step 102: If the execution result is successful unlocking, then inject a simulated door opening trigger signal into the vehicle's onboard bus.

[0029] In some examples, successful unlocking is one outcome, indicating that after the target vehicle's body control module receives the unlock command, it completes the release of the anti-theft lock and successful authorization verification, demonstrating that the target vehicle is now in a legal state that allows subsequent wake-up operations. For example, if the test terminal reads the status identifier "UNLOCK_SUCCESS" from the vehicle remote control application on the mobile terminal, or receives a specific status code indicating successful unlocking, the outcome can be determined as successful unlocking. The vehicle bus is the core channel for data communication and command transmission between various electronic control modules within the target vehicle. It is used to realize information interaction between different functional modules within the vehicle and is a key medium for the test terminal to inject signals into the vehicle and obtain vehicle status data. A physical connection between the test terminal and the vehicle bus can be established through the bus interface or test interface reserved by the target vehicle, ensuring that the test terminal can send signals to the bus and receive data transmitted by the bus. For example, if the target vehicle is equipped with a Controller Area Network (CAN) bus, which connects core components such as the body control module, vehicle infotainment system, and power management module, the test terminal can establish a connection with the CAN bus through the bus interface device to achieve signal injection and interaction. A simulated door opening trigger signal is an electrical signal or data frame conforming to the vehicle bus communication protocol. It simulates the action of a user opening a car door in a real-world scenario, triggering the target vehicle's wake-up process, rather than a real door opening signal generated by physical door operation. The test terminal can pre-configure the signal format, parameters, and transmission rules according to the target vehicle's bus communication specifications. The test terminal's signal generation module then generates the corresponding signal according to this configuration. For example, a simulated door opening trigger signal is a data frame conforming to the target vehicle's controller area network bus protocol. This data frame contains key information such as door status identifiers and trigger types, and can be recognized by the target vehicle's body control module as a legitimate door opening trigger command, equivalent to the signal generated by a real door opening operation. If the execution result is successful unlocking, the process of injecting the simulated door opening trigger signal into the target vehicle's vehicle bus involves the test terminal initiating the signal injection process after confirming that the target vehicle has completed legitimate unlocking. The pre-generated simulated door opening trigger signal is transmitted to the target vehicle's vehicle bus to trigger vehicle wake-up. This operation is contingent on successful unlocking, ensuring compliance with the logical order of unlocking before opening in mass production scenarios and preventing unauthorized signal injection.

[0030] By implementing step 102, after confirming successful unlocking, a simulated door opening trigger signal is injected into the vehicle's onboard bus to trigger vehicle wake-up. This allows the wake-up trigger action to be directly controlled by the test side, reducing reliance on uncertainties in remote communication and thus improving the controllability of wake-up trigger timing and conditions.

[0031] Step 103: Obtain the status response data of multiple vehicle domains in the target vehicle in response to the simulated door opening trigger signal.

[0032] In some examples, multiple vehicle domains are collections of independent functional areas within the target vehicle, divided according to function and undertaking different core control tasks. These areas jointly participate in the vehicle wake-up process, and their state changes directly reflect the vehicle's wake-up status. Multiple vehicle domains may include the target vehicle's power-related functional domains, vehicle infotainment system-related functional domains, and body control-related functional domains. These areas are responsible for vehicle power supply management, vehicle infotainment system operation, and body status control, respectively. Status response data are collectable data generated and output by multiple vehicle domains after receiving a simulated door opening trigger signal, during the wake-up process and adjustment of operating status. This data objectively characterizes the operating status and wake-up progress of each vehicle domain. For example, the power supply voltage data output by the power-related functional domain, the system startup status indicator output by the vehicle infotainment system-related functional domain, and the door status confirmation signal output by the body control-related functional domain all directly reflect the response of the corresponding vehicle domain to the simulated door opening trigger signal.

[0033] For example, after the test terminal injects the simulated door opening trigger signal, it maintains stable communication with the target vehicle controller's local area network bus and simultaneously starts the built-in data acquisition program, which is pre-configured with parsing rules conforming to the target vehicle bus protocol. After receiving the simulated door opening trigger signal, multiple vehicle domains each start their wake-up process and continuously output status data. Power-related functional domains transmit real-time data on changes in power supply voltage and current, vehicle-mounted system-related functional domains provide feedback on system startup progress, and body control-related functional domains send door status confirmation and security status signals. All of this data is transmitted in real-time through the vehicle bus. The test terminal receives and parses this data at a preset frequency, classifies and summarizes the status response data of different vehicle domains, and ensures that the data completely covers the wake-up status of each core vehicle domain, providing comprehensive and accurate data support for the subsequent determination of the vehicle wake-up test results.

[0034] By implementing step 103, the state response data of multiple vehicle domains in the target vehicle to the simulated door opening trigger signal are obtained. The response of the vehicle to the wake-up trigger signal can be observed from the perspective of different vehicle domains, so that the judgment of the wake-up status of the whole vehicle no longer depends on a single module or a single phenomenon, which can improve the comprehensiveness and reliability of test observation.

[0035] Step 104: Based on the status response data, determine the whole vehicle wake-up test results of the target vehicle.

[0036] In some examples, the whole vehicle wake-up test result is the final judgment on whether the target vehicle has completed a valid full-link wake-up after receiving a simulated door opening trigger signal. It can include two states: "wake-up successful" and "wake-up failed". It directly reflects the wake-up performance of the target vehicle in response to the door opening trigger after remote unlocking and is the core output of the whole vehicle wake-up test. The test terminal can perform comprehensive analysis based on the status response data of multiple vehicle domains collected through preset judgment logic, and finally generate the corresponding judgment result.

[0037] For example, after the test terminal summarizes the status response data of multiple vehicle domains, it immediately calls the built-in judgment logic module. This module has been pre-configured with core activation standards that meet the wake-up performance requirements of the target vehicle. The judgment logic module parses the power supply status data of the power-related functional domain, the operating status identifier of the vehicle-mounted functional domain, and the response signal of the body control-related functional domain one by one in a preset order, and compares the consistency of each data with the wake-up activation standard. If the status response data of all core vehicle domains meet the standard requirements, the test terminal generates a "wake-up successful" vehicle wake-up test result. If any core data fails to meet the standard, a "wake-up failed" result is output. At the same time, the test result is associated with and stored with the corresponding status response data to provide an intuitive basis for subsequent vehicle wake-up performance analysis.

[0038] By implementing step 104, the vehicle wake-up test results of the target vehicle are determined based on the acquired state response data. This transforms the vehicle wake-up process into a clear test conclusion, making the test results verifiable and consistent, which facilitates subsequent test analysis and verification.

[0039] In summary, this application embodiment obtains the execution result of the unlocking command remotely sent by the mobile terminal to the target vehicle, and performs subsequent operations only after confirming successful unlocking. This ensures that the vehicle wake-up test is based on the premise that the vehicle has already been unlocked, guaranteeing that the test process conforms to the vehicle's existing remote unlocking logic and effectively reflecting the vehicle's wake-up state in actual usage scenarios. Upon successful unlocking, the test terminal injects a simulated door opening trigger signal into the target vehicle's onboard bus to trigger vehicle wake-up. Compared to relying entirely on the mobile terminal to send door opening commands, this method allows the wake-up trigger action to be controlled by the test side, improving the controllability of the wake-up trigger timing and conditions. By obtaining the status response data from multiple vehicle domains in the target vehicle in response to the simulated door opening trigger signal, the judgment of the vehicle's wake-up state no longer depends on a single module or phenomenon, but is based on a comprehensive analysis of feedback from multiple vehicle domains, improving the comprehensiveness and reliability of the wake-up test results. Furthermore, determining the vehicle wake-up test results based on the obtained status response data from multiple vehicle domains transforms the entire vehicle wake-up process into a clear test conclusion, making the test results verifiable and consistent, facilitating subsequent test analysis and verification. In summary, the vehicle wake-up test method based on a mobile terminal provided in this application, under the premise of confirming successful remote unlocking of the vehicle, determines the vehicle wake-up result by injecting a simulated door opening trigger signal into the vehicle bus and integrating the state responses of multiple vehicle domains. This enables a vehicle wake-up test with controllable wake-up triggering and comprehensive and reliable judgment criteria.

[0040] In some embodiments, step 101 may include: calling a preset application interface of the mobile terminal to remotely send an unlocking command to the target vehicle; obtaining a response message returned by the target vehicle to the preset application interface; and parsing the status code field in the response message to determine the execution result.

[0041] In some examples, the preset application programming interface (API) is a standardized communication interface provided by the vehicle remote control application on the mobile terminal to external devices. It receives external trigger commands and executes corresponding remote vehicle control operations. It also establishes a legitimate communication link between the test terminal and the vehicle control function of the mobile terminal, ensuring that the sending of the unlock command conforms to the application's operating logic and security specifications. The process of calling the mobile terminal's preset API to remotely send the unlock command to the target vehicle involves the test terminal not directly operating the mobile terminal's application interface. Instead, it initiates a command request through the standardized preset API, triggering the mobile terminal's vehicle remote control application to automatically send the unlock command to the target vehicle. This ensures that the command sending process conforms to the application's operating logic in a mass production scenario, avoiding uncertainties caused by manual operation. For example, the test terminal configures a Hypertext Transfer Protocol (HTTP) request based on the interface documentation, passing in parameters such as the target vehicle identification code and user authorization token, and calls the vehicle remote control API to trigger the mobile terminal's vehicle remote control application to generate the unlock command and initiate the remote sending process. The response message is a structured data packet relayed by the cloud service platform to the mobile terminal's preset application interface after the target vehicle executes the unlock command. It informs the mobile terminal of the unlock command execution status, including execution status and relevant identification information, and serves as the direct data carrier for the test terminal to obtain the unlock execution result. The response message can be a data packet in JavaScript Object Notation (JSON) format, including a status code field, a target vehicle identification code field, and an operation timestamp field. The status code field directly relates to the unlock command execution result. The status code field is a specific data field in the response message used to standardize the identification of the unlock command execution result. Its value follows a preset encoding rule; different codes correspond to different execution statuses and are the core basis for quickly determining whether the unlock was successful. For example, the "status_code" field in the response message uses numeric encoding, where "200" represents successful unlock command execution, "401" represents invalid authorization, "404" represents the target vehicle not found, and "500" represents an execution error on the vehicle side.

[0042] For example, the test terminal can receive response messages forwarded from the target vehicle via a communication link with the mobile terminal's preset application interface, ensuring that the test terminal can obtain complete and tamper-proof unlock status feedback data. For instance, after calling the vehicle remote control application interface, the test terminal starts a data monitoring process. When the mobile terminal's preset application interface receives the response message forwarded from the cloud, it pushes the message to the test terminal via a network connection. The test terminal receives and stores the message for later use. The test terminal can interpret the extracted status code field and, according to preset encoding mapping rules, convert the status code into a clear execution result of "unlock successful" or "unlock failed," ensuring that the judgment of the execution result is standardized and unambiguous. For example, if the test terminal extracts a status code field value of "200" after parsing the response message, and queries the built-in mapping table to find that this code corresponds to "unlock successful," then the execution result of this unlock command is determined to be unlock successful. If the extracted status code is "401" or "500," then after querying the mapping table, the execution result is determined to be unlock failed.

[0043] By implementing the above embodiments, the mobile terminal's preset application interface is called to send an unlock command, and the status code field in the response message returned by the vehicle is parsed to determine the unlock execution result. This enables the test terminal to use clear and standardized data results as the basis for judging the unlock success, avoids relying on indirect phenomena to judge the unlock status, and can provide reliable preconditions for subsequent wake-up triggering, thereby improving the certainty and consistency of the overall test process.

[0044] In some embodiments, the aforementioned step 102 may include: determining the authorization start time based on a first timestamp carried in the response message and a second timestamp of the response message received by the preset application interface; determining a signal injection time window based on the authorization start time and a preset authorization validity period; and injecting a simulated door opening trigger signal into the vehicle bus through the bus interface within the signal injection time window.

[0045] In some examples, the first timestamp is a time identifier carried in the response message, representing the time the target vehicle generated the response message. It reflects the time node when the target vehicle sent the response message. The corresponding timestamp data can be extracted from the response message received by the test terminal according to the structured format and field definitions of the message. For example, the timestamp field can be "2025-12-22T14:30:00.123Z". The second timestamp is a reception time identifier recorded by the mobile terminal system when the mobile terminal's preset application interface receives the response message from the target vehicle. It reflects the actual time when the response message arrives at the mobile terminal and is used to correct the impact of network transmission delay on the authorization time determination. The system time module can be automatically called to record the current time at the instant the mobile terminal's preset application interface receives the response message, forming the second timestamp and synchronizing it to the test terminal. For example, the time recorded by the mobile terminal system can be "2025-12-22T14:30:00.345Z", which precisely corresponds to the instant when the preset application interface receives the response message and includes the delay information of the message being transmitted from the vehicle to the mobile terminal via the cloud. The authorization activation start time is the reference time when the remote unlocking authorization of the target vehicle officially takes effect, allowing subsequent injection of simulated door opening trigger signals. This time can be obtained by correcting network transmission latency to ensure consistency with the actual authorization activation time on the vehicle side. In the implementation process, it can be calculated based on the first and second timestamps using a preset time synchronization algorithm to eliminate the interference of network transmission latency on the authorization time determination. For example, the test terminal extracts the first timestamp "2025-12-22T14:30:00.123Z" and the second timestamp "2025-12-22T14:30:00.345Z", calculates the transmission latency to be 222 milliseconds, and after latency equalization correction, determines the authorization activation start time as "2025-12-22T14:30:00.234Z".

[0046] The preset authorization validity period is a fixed length of time during which the remote unlocking authorization of the target vehicle remains valid from the start time of authorization. This preset authorization validity period can be pre-configured to adapt to the authorization logic of different vehicle models, ensuring that the authorization is still valid when the simulated door opening trigger signal is injected. The corresponding preset authorization validity period can also be pre-configured in the test terminal according to factors such as the mass production authorization logic of the target vehicle and the stability of the network environment. The value of the preset authorization validity period can be from 200 milliseconds to 3 seconds. The signal injection time window is the valid time period during which a simulated door opening trigger signal is allowed to be injected into the vehicle bus. It is defined by the authorization start time and the preset authorization validity period, and is the time range that ensures the legality and validity of the signal injection. The test terminal can automatically calculate the start and end times of the signal injection time window by adding the preset authorization validity period to the authorization start time. For example, by adding a 2-second preset authorization validity period to the authorization start time "2025-12-22T14:30:00.234Z", the time window formed is "2025-12-22T14:30:00.234Z - 2025-12-22T14:30:02.234Z".

[0047] It should be noted that the first timestamp carried in the response message is the precise moment when the target vehicle completes the unlocking operation and generates feedback information, directly reflecting the actual unlocking completion node on the vehicle side. The second timestamp, which is preset for the application interface to receive the response message, is the message reception time recorded on the mobile terminal side. The time difference between the two is essentially the network latency of transmitting the unlocking feedback information from the vehicle side to the mobile terminal via the cloud service platform. Through preset time synchronization and latency correction algorithms, the interference of this transmission latency on the authorization effective time determination can be eliminated, ultimately obtaining the authorization effective start time consistent with the actual authorization effective state on the vehicle side. If only a single timestamp is relied upon to determine the authorization effective time, network latency will cause the determination result to deviate from the actual state on the vehicle side. This may cause the subsequent simulated door opening trigger signal injection to exceed the effective range of remote authorization, violating the "authorize first, then act" security logic in mass production scenarios. At the same time, the uncertainty of timing determination will cause inconsistencies in the triggering conditions of different test batches, affecting the comparability of test results. The accurate authorization effective start time is the core benchmark for defining the subsequent signal injection time window. Without this benchmark, the signal injection timing will be chaotic, and a stable test trigger standard cannot be established. It can ensure that the injection of simulated door opening trigger signals is always within the legal authorization period, in line with the mass production safety authorization logic, and establish a standardized timing benchmark by eliminating network latency interference. This ensures that the signal injection timing remains consistent in different test scenarios and network environments, which can improve the repeatability and consistency of vehicle wake-up tests. It provides an accurate and reliable timing basis for the quantitative evaluation of vehicle wake-up response speed, stability and other performance indicators and cross-model comparative analysis.

[0048] For example, after the test terminal receives the response message, it first extracts the first timestamp generated by the target vehicle side from the message, and simultaneously receives the second timestamp of the message received by the preset application interface synchronized by the mobile terminal. It then calculates the message transmission delay using a built-in time synchronization algorithm and completes time correction to determine the authorization start time. Subsequently, the test terminal calls the pre-configured preset authorization validity period parameter, and automatically calculates the start and end times of the signal injection time window, using the authorization start time as the starting point, ensuring that signal injection occurs within the authorization validity period. Before the test, a stable physical connection has been established between the test terminal and the target vehicle's controller area network (CLAN) bus via the CLAN bus interface device. Once the signal injection time window starts, the test terminal immediately transmits the pre-generated simulated door opening trigger signal, conforming to the target vehicle's bus protocol, to the vehicle bus. The entire process, through precise time calculation and window control, ensures both the legality and validity of the signal injection and establishes a standardized trigger timing benchmark, effectively avoiding timing fluctuations caused by network latency and guaranteeing the repeatability and consistency of the test results.

[0049] By implementing the above embodiments, the authorization start time is determined by combining the timestamp carried in the response message and the interface receiving timestamp, and the signal injection time window is calculated accordingly. This allows the simulated door opening trigger signal to be injected into the vehicle bus in a predetermined sequence within the authorized effective range. As a result, the wake-up trigger time base is clear and configurable, reducing the impact of timing drift on the test results and improving the repeatability and comparability of wake-up tests in different test rounds.

[0050] In some embodiments, the aforementioned simulated door opening trigger signal may include a first message indicating that remote authorization is effective and a second message indicating that the target door is open; before injecting the simulated door opening trigger signal into the aforementioned vehicle bus through the bus interface, the method may further include: obtaining signal configuration parameters corresponding to the vehicle model identifier of the target vehicle, wherein the signal configuration parameters may include a first definition rule corresponding to the aforementioned first message and a second definition rule corresponding to the second message; generating a first message and a second message that conform to the vehicle model identifier based on the first definition rule and the second definition rule; injecting the simulated door opening trigger signal into the vehicle bus through the bus interface may include: sequentially injecting the first message and the second message into the vehicle bus through the bus interface.

[0051] In some examples, the first message is a core component of the simulated door opening trigger signal. It is specifically used to transmit standardized information indicating "remote authorization has taken effect" to components such as the target vehicle's body control module, ensuring that subsequent door opening signals are recognized as legitimate authorized operations and preventing interception due to authorization verification failure. For example, the first message is a Controller Area Network (CLAN) bus message, identified as 0x28F, with a data segment containing the remote authorization status signal "PKE_Auth=Valid," explicitly informing the vehicle that the current door opening trigger originates from legitimate remote authorization. The second message is another component of the simulated door opening trigger signal, used to transmit the action command "specific door open" to the target vehicle. It simulates the physical operation of a real user unlocking and opening the door, and is the direct action signal triggering the vehicle wake-up process. For example, the second message is a CLAN bus message, identified as 0x3E7, with a data segment containing the left front door status signal "DCU_FL_doorFLSts=1," indicating that the target vehicle's left front door is open.

[0052] The signal configuration parameters corresponding to the target vehicle's model identifier are a standardized set of parameters adapted to the target vehicle's model. These include first and second definition rules required to generate the first and second messages. These rules ensure compatibility between the simulated door opening trigger signal and the target vehicle's bus protocol and security verification logic, improving the test method's vehicle model adaptability. The parameters can be retrieved from a locally stored parameter library using the target vehicle's model identifier or obtained from the test management server via the network. The first definition rule is a standardized specification within the signal configuration parameters specifically used to generate the first message. It clarifies the bus type, message identifier, data segment structure, signal encoding method, and verification field requirements of the first message, ensuring that the first message can pass the vehicle gateway and security verification. For example, the first definition rule includes: bus type is Controller Area Network (CAN) bus, message identifier is 0x28F, data length is 8 bytes, and the 0-3 bits of the 3rd byte are a remote authorization status field, encoded as "0x01" to indicate valid authorization. It also requires compliance with counter increment rules and Cyclic Redundancy Check (CRC) requirements. The second definition rule is a standardized specification in the signal configuration parameters specifically used to generate the second message. It is used to clarify the core elements of the second message, such as the bus type, message identifier, door status signal field, signal value range, and data refresh frequency, to ensure that the second message can be correctly identified by the vehicle as a legitimate door opening action. For example, the second definition rule includes: the bus type is the Controller Area Network (CAN) bus, the message identifier is 0x3E7, the data length is 8 bytes, the 4th to 7th bits of the 5th byte are the left front door status field, the encoding "0x01" indicates that the door is open and "0x00" indicates that the door is closed, and the message refresh period is 100 milliseconds.

[0053] The process of generating the first and second messages that conform to the vehicle model identifier based on the first and second definition rules means that the test terminal does not directly use fixed format messages, but dynamically generates legal messages adapted to the vehicle model according to the exclusive definition rules of the target vehicle. This ensures the compatibility and effectiveness of signal injection and can solve the problem of poor vehicle model compatibility in traditional testing methods. For example, after the test terminal retrieves the first definition rule (message ID 0x28F, authorization signal code 0x01) and the second definition rule (message ID 0x3E7, left front door opening code 0x01) of the target vehicle model, the message generation module fills in the data segments according to the rules, calculates the cyclic redundancy check value, and generates complete first and second messages.

[0054] The process of sequentially injecting the first and second messages into the vehicle bus via the bus interface reflects the mass production scenario logic of confirming authorization before executing the door opening action. This ensures that the signal transmission order conforms to the vehicle's safety verification process and avoids the signal being judged as abnormal due to the order being reversed. For example, the test terminal establishes a connection with the target vehicle's controller area network bus via the controller area network bus interface, first sending the first message (ID0x28F, authorization valid), and then sending the second message (ID0x3E7, left front door open) after an interval of 50 milliseconds. This ensures that the vehicle completes the authorization verification before responding to the door opening action.

[0055] By implementing the above embodiments, signal configuration parameters corresponding to vehicle model identification are introduced, and authorization messages and door opening messages that conform to vehicle model characteristics are generated according to defined rules. This ensures that the simulated door opening trigger signal is consistent with the actual bus signal of the target vehicle in terms of format and semantics, avoiding wake-up abnormalities caused by signal mismatch. This improves the applicability of wake-up testing on different vehicle models and platforms and the consistency of test results.

[0056] In some embodiments, the aforementioned plurality of vehicle domains may include a power domain, an in-vehicle infotainment domain, and a body domain; the aforementioned step 103 may include: initiating a signal monitoring time window of a preset duration after injecting a simulated door opening trigger signal; within the signal monitoring time window, acquiring a first monitoring data stream, a second monitoring data stream, and a third monitoring data stream in parallel through a bus interface, wherein the first monitoring data stream contains parameters characterizing the operating state of the power domain, the second monitoring data stream contains parameters characterizing the operating state of the in-vehicle infotainment domain, and the third monitoring data stream contains parameters characterizing the operating state of the body domain; and using the first monitoring data stream, the second monitoring data stream, and the third monitoring data stream together as state response data.

[0057] In some examples, the power domain is the core functional domain in the target vehicle responsible for power management and distribution. It includes related modules and links that provide stable power to various electronic components of the vehicle. Its operating status directly determines whether the vehicle has the energy foundation for wake-up. For example, the power domain may include the functional domain of related modules such as the Battery Management Unit (BMU), DC-DC converter, Power Distribution Unit (PDU), and Ignition Switch Controlled Power Supply (KL15). It mainly undertakes responsibilities such as battery status monitoring, voltage conversion, and power supply control for each domain.

[0058] The vehicle infotainment domain is the functional domain in the target vehicle responsible for in-vehicle infotainment, human-machine interaction, and execution of core control commands. It includes the vehicle infotainment host and related auxiliary functional modules, and its wake-up status directly reflects the wake-up effect at the vehicle user interaction level. For example, the vehicle infotainment domain may include the functional domains of the in-vehicle infotainment host (IVI host), the in-vehicle display control module, the navigation system module, and the multimedia control unit, and is mainly responsible for interface rendering, command response, and operation of entertainment functions.

[0059] The vehicle body domain is the core functional domain in the target vehicle responsible for basic functions such as vehicle body attitude control, door / window / security management, etc. It includes vehicle body control related modules, and its status response directly reflects the execution effect of the simulated door opening signal. For example, the vehicle body domain may include the functional domains of the vehicle body control module, the Passive Keyless Entry (PKE) module, and the Door Control Unit (DCU), which are mainly responsible for door status control, anti-theft alarm, and vehicle body signal feedback.

[0060] The preset signal monitoring time window is a fixed period of time during which the test terminal continuously collects status data from multiple vehicle domains after the simulated door opening trigger signal is injected. This duration is pre-configured to ensure that the entire process of state changes from sleep to wake-up of each domain can be fully captured. The fixed duration can be preset by the test terminal based on factors such as the wake-up response characteristics of the target vehicle and the startup time of each domain. The value range is 1 to 5 seconds. For example, a 3-second monitoring time window has been verified through multiple rounds of testing. This duration can cover the complete link of power domain power-on, vehicle system domain startup, and vehicle body domain status confirmation. It can also avoid data loss due to too short a duration or resource waste due to too long a duration.

[0061] The first monitoring data stream is a continuous data sequence specifically collected by the test terminal within the signal monitoring time window, representing the operating status of the power domain. It is the core data carrier reflecting the wake-up status of the power domain. The test terminal can continuously receive status data transmitted by each module of the power domain through the vehicle bus at a preset frequency via the bus interface, forming a continuous data stream. The first monitoring data stream can contain parameters representing the operating status of the power domain. These parameters are specific quantitative indicators or status indicators that objectively reflect the power domain's power supply capacity and operating mode, such as the KL15 power switch status ("1" indicates on, "0" indicates off), DC-DC output voltage, PDU relay on / off status, and continuous data sequence of BMU battery output current.

[0062] The second monitoring data stream is a continuous data sequence specifically collected by the test terminal within the signal monitoring time window, representing the operating status of the vehicle-mounted domain. It is the core data carrier reflecting the wake-up status of the vehicle-mounted domain. It can continuously receive status data transmitted by various modules of the vehicle-mounted domain through the vehicle bus at a preset frequency via the bus interface, forming a continuous data stream. The second monitoring data stream can contain parameters representing the operating status of the vehicle-mounted domain. These parameters are specific quantitative indicators or status indicators that can objectively reflect the information processing capabilities and functional operating status of the vehicle-mounted domain, such as the vehicle-mounted heartbeat signal, the on-screen display status ("1" indicates on, "0" indicates off), the navigation system startup indicator, and a continuous data sequence of core process operating status.

[0063] The third monitoring data stream is a continuous data sequence specifically collected by the test terminal within the signal monitoring time window, representing the operating status of the vehicle body domain. It is the core data carrier reflecting the response of the vehicle body domain to the simulated door opening signal. The test terminal can continuously receive status data transmitted by each module of the vehicle body domain through the vehicle bus at a preset frequency via the bus interface, forming a continuous data stream. The third monitoring data stream can contain parameters representing the operating status of the vehicle body domain. These parameters are specific quantitative indicators or status indicators that can objectively reflect the operation of the vehicle body domain's door control and security monitoring functions, such as actual door status feedback ("1" indicates open, "0" indicates closed), BCM security status indicators ("0" indicates normal, "1" indicates alarm), PKE authorization verification results ("Valid" indicates valid, "Invalid" indicates invalid), and a continuous data sequence of anti-theft alarm signals.

[0064] The test terminal does not use the data stream of a single domain as the basis for judgment. Instead, it summarizes and integrates the monitoring data streams of the power domain, vehicle domain, and body domain to form comprehensive and complete status response data, ensuring that the subsequent wake-up result judgment can cover the core link of vehicle wake-up. For example, the test terminal synchronously integrates the KL15 voltage data (first data stream), vehicle heartbeat data (second data stream), and door status feedback data (third data stream) collected within a 3-second monitoring time window according to the timestamp to form status response data that includes complete status changes in the three domains.

[0065] Through the implementation of the above embodiments, after the simulated door opening trigger signal is injected, the operating status data of the power domain, vehicle domain and body domain are collected in parallel within the preset monitoring time window. This enables the test process to simultaneously observe the vehicle's response to the wake-up trigger from multiple vehicle domains, avoiding the need to rely on a single module or a single phenomenon for judgment, and improving the comprehensiveness and objectivity of the wake-up test status collection.

[0066] In some embodiments, the aforementioned step 104 may include: determining, based on the first monitoring data stream, the second monitoring data stream, and the third monitoring data stream, whether the power domain, the vehicle infotainment domain, and the body domain meet their respective wake-up conditions; if the power domain, the vehicle infotainment domain, and the body domain all meet their respective wake-up conditions, then the vehicle wake-up test result is determined to be a successful wake-up; otherwise, the vehicle wake-up test result is determined to be a failed wake-up.

[0067] In some examples, the test terminal can analyze the specific parameters in the three monitoring signals and compare them one by one with the preset wake-up conditions in the power domain, vehicle domain, and body domain to determine whether each domain has completed a valid wake-up, providing a domain-specific basis for the final determination of the vehicle wake-up result. For example, the domain-specific determination module of the test terminal reads the KL15 power on / off status and DCDC output voltage in the first monitoring data stream and compares them with the power domain wake-up condition "KL15 is continuously on and the DCDC output voltage is stable at 13.5-14.5 volts"; reads the vehicle heartbeat frequency in the second monitoring data stream and compares it with the vehicle domain wake-up condition "the vehicle heartbeat frequency is stable above 1 Hz"; reads the door status and security status in the third monitoring data stream and compares them with the body domain wake-up condition "the door status is consistent with the injected signal and the security status is normal", thereby determining whether each domain meets the wake-up conditions. The vehicle wake-up is considered successful only if the power domain, vehicle infotainment domain, and body domain all successfully wake up. Failure to meet the wake-up conditions in any domain results in a failure, ensuring that the test results accurately reflect the completeness and effectiveness of the vehicle wake-up. For example, if the domain judgment results show that the power domain KL15 is connected and the DC-DC voltage is stable, the vehicle infotainment domain heartbeat frequency meets the standard, and the body domain door status matches and security is normal, and all three domains meet the wake-up conditions, then the comprehensive judgment module determines that the vehicle wake-up test result is a successful wake-up. If the vehicle infotainment domain heartbeat frequency does not reach the preset threshold, but the other two domains meet the conditions, the comprehensive judgment module still determines that the vehicle wake-up test result is a failed wake-up.

[0068] By implementing the above embodiments, it is determined whether the power domain, vehicle domain, and body domain meet their respective wake-up conditions, and the whole vehicle wake-up test results are determined accordingly. This makes the judgment of wake-up results clear and uniform, which helps to eliminate subjective judgment differences and improves the consistency and comparability of test results under different testers and different test environments.

[0069] In some embodiments, the aforementioned method may further include: if the vehicle wake-up test result is determined to be a wake-up failure, injecting a rollback control signal into the vehicle bus through the bus interface, wherein the rollback control signal may include a third message for restoring the state of the target door to closed, and a fourth message for indicating the revocation of remote authorization.

[0070] In some examples, the rollback control signal is a standardized set of bus signals generated by the test terminal based on a preset rollback strategy to restore the vehicle's initial state. It can consist of a third message and a fourth message, and its format conforms to the target vehicle's onboard bus protocol. It can be recognized and executed by core components such as the body control module, and is the key signal carrier for realizing vehicle state rollback. The third message is the core component of the rollback control signal, specifically used to transmit the instruction "target door restored to closed" to the target vehicle's body control module, canceling the door opening state caused by the previously injected simulated door opening trigger signal, and ensuring that the door state returns to its initial state. The test terminal can generate a door closing status message that conforms to the bus protocol according to the reverse logic of the second definition rule in the signal configuration parameters corresponding to the target vehicle's model identifier. For example, the controller area network bus message, with message identifier 0x3E7, contains the left front door status signal "DCU_FL_doorFLSts=0" in the data segment. This encoding represents the left front door being in a closed state according to the target vehicle's signal definition rule, and can be recognized by the door control unit to execute the door closing logic. The fourth message is another key component of the rollback control signal. It is specifically used to transmit the instruction "remote authorization revoked" to the keyless entry module and body control module of the target vehicle, terminating the temporary authorization for this test, ensuring that the vehicle anti-theft system is restored to the normal security level, and avoiding the risk of unauthorized operation. The test terminal can generate an authorization revocation message that conforms to the bus protocol based on the reverse logic of the first defined rule in the signal configuration parameters corresponding to the target vehicle's model identifier. For example, the controller area network bus message, with the message identifier 0x28F, contains the remote authorization status signal "PKE_Auth=Invalid" in the data segment. This code represents the failure of remote authorization according to the signal definition rule of the target vehicle, and can be verified by the keyless entry module to revoke the relevant authorization permissions.

[0071] Through the implementation of the above embodiments, when the vehicle wake-up test fails, the door status and remote authorization status are restored to the expected initial state by injecting a rollback control signal into the vehicle bus. This allows the vehicle test environment to quickly return to a stable state that can be tested again, avoiding interference from abnormal states with subsequent test results. This is beneficial for conducting multiple rounds of wake-up tests continuously and maintaining the stability and consistency of test results.

[0072] Furthermore, as an implementation of the foregoing method embodiments, this application also provides a test terminal for implementing the foregoing method embodiments. This device embodiment corresponds to the foregoing method embodiments. For ease of reading, this test terminal embodiment will not repeat the details of the foregoing method embodiments one by one, but it should be understood that the device in this application embodiment can correspondingly implement all the contents of the foregoing method embodiments. For example... Figure 2As shown, the test terminal 20 includes: a result acquisition unit 201, a signal injection unit 202, a feedback acquisition unit 203, and a result determination unit 204. The result acquisition unit 201 is used to acquire the execution result of the target vehicle in response to the unlocking command, wherein the unlocking command is a command remotely sent from the mobile terminal to the target vehicle. The signal injection unit 202 is used to inject a simulated door opening trigger signal into the vehicle's onboard bus if the execution result is successful unlocking. The feedback acquisition unit 203 is used to acquire the status response data fed back by multiple vehicle domains in the target vehicle in response to the simulated door opening trigger signal. The result determination unit 204 is used to determine the vehicle wake-up test result of the target vehicle based on the status response data.

[0073] In some embodiments, the result acquisition unit 201 is further configured to call a preset application interface of the mobile terminal to remotely send an unlocking command to the target vehicle; acquire the response message returned by the target vehicle to the preset application interface; and parse the status code field in the response message to determine the execution result.

[0074] In some embodiments, the signal injection unit 202 is further configured to determine the authorization start time based on the first timestamp carried in the response message and the second timestamp of the response message received by the preset application interface; determine the signal injection time window according to the authorization start time and the preset authorization validity period; and inject a simulated door opening trigger signal into the vehicle bus through the bus interface within the signal injection time window.

[0075] In some embodiments, the simulated door opening trigger signal includes a first message indicating that remote authorization is effective and a second message indicating that the target door is opened; the test terminal 20 further includes a signal generation unit, which is used to obtain signal configuration parameters corresponding to the vehicle model identifier of the target vehicle, wherein the signal configuration parameters include a first definition rule corresponding to the first message and a second definition rule corresponding to the second message; based on the first definition rule and the second definition rule, a first message and a second message conforming to the vehicle model identifier are generated; the signal injection unit 202 is also used to inject the first message and the second message into the vehicle bus in sequence through the bus interface.

[0076] In some embodiments, the multiple vehicle domains include a power domain, an in-vehicle infotainment domain, and a body domain; the feedback acquisition unit 203 is further configured to initiate a signal monitoring time window of a preset duration after injecting a simulated door opening trigger signal; within the signal monitoring time window, a first monitoring data stream, a second monitoring data stream, and a third monitoring data stream are acquired in parallel through a bus interface, wherein the first monitoring data stream contains parameters characterizing the operating state of the power domain, the second monitoring data stream contains parameters characterizing the operating state of the in-vehicle infotainment domain, and the third monitoring data stream contains parameters characterizing the operating state of the body domain; the first monitoring data stream, the second monitoring data stream, and the third monitoring data stream are used together as state response data.

[0077] In some embodiments, the result determination unit 204 is further configured to determine, based on the first monitoring data stream, the second monitoring data stream, and the third monitoring data stream, whether the power domain, the vehicle infotainment domain, and the body domain meet their respective wake-up conditions; if the power domain, the vehicle infotainment domain, and the body domain all meet their respective wake-up conditions, then the vehicle wake-up test result is determined to be a successful wake-up; otherwise, the vehicle wake-up test result is determined to be a failed wake-up.

[0078] In some embodiments, the result determination unit 204 is further configured to inject a rollback control signal into the vehicle bus via the bus interface if the vehicle wake-up test result is determined to be a wake-up failure. The rollback control signal includes a third message for restoring the state of the target door to closed and a fourth message for indicating the revocation of remote authorization.

[0079] This application also provides a computer-readable storage medium storing computer-executable instructions or computer programs, which, when executed by a processor, will cause the processor to perform any step of the vehicle wake-up test method based on a mobile terminal provided in this application.

[0080] In some embodiments, the computer-readable storage medium may be a random access memory (RAM), a read-only memory (ROM), flash memory, a magnetic surface memory, an optical disc, or a compact disc read-only memory (CD-ROM); or it may be a variety of devices that include one or any combination of the above-mentioned memories.

[0081] In some embodiments, computer-executable instructions may take the form of programs, software, software modules, scripts, or code, written in any form of programming language (including compiled or interpreted languages, or declarative or procedural languages), and may be deployed in any form, including as stand-alone programs or as modules, components, subroutines, or other units suitable for use in a computing environment.

[0082] In some embodiments, computer-executable instructions may, but do not necessarily, correspond to files in a file system, and may be stored as part of a file that holds other programs or data, for example, in one or more scripts in a HyperText Markup Language (HTML) document, in a single file dedicated to the program in question, or in multiple co-located files (e.g., files that store one or more modules, subroutines, or code sections).

[0083] In some embodiments, computer-executable instructions may be deployed to execute on an electronic device, or on multiple electronic devices located at one location, or on multiple electronic devices distributed across multiple locations and interconnected via a communication network.

[0084] like Figure 3 As shown, this application also provides an electronic device 30, including a memory 310, a processor 320, and a computer program 311 stored in the memory 310 and executable on the processor. When the processor 320 executes the computer program 311, it implements any step of the above-described vehicle wake-up test method based on a mobile terminal.

[0085] This application also provides a computer program product comprising a computer program or computer-executable instructions stored in a computer-readable storage medium. The processor of an electronic device reads the computer program or computer-executable instructions from the computer-readable storage medium and executes the computer program or computer-executable instructions, causing the electronic device to perform any step of the vehicle wake-up test method based on a mobile terminal described above.

[0086] The above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application.

Claims

1. A vehicle wake-up test method based on a mobile terminal, characterized in that, Applied to a test terminal, the method includes: Obtain the execution result of the target vehicle in response to the unlocking command, wherein the unlocking command is a command remotely sent from the mobile terminal to the target vehicle; If the execution result is successful unlocking, a simulated door opening trigger signal is injected into the vehicle's onboard bus. Acquire the status response data of multiple vehicle domains in the target vehicle in response to the simulated door opening trigger signal; Based on the status response data, the vehicle wake-up test result of the target vehicle is determined.

2. The method according to claim 1, characterized in that, The process of obtaining the target vehicle's execution result in response to the unlock command includes: The mobile terminal's preset application interface is invoked to remotely send the unlock command to the target vehicle; Obtain the response message returned by the target vehicle to the preset application interface; The status code field in the response message is parsed to determine the execution result.

3. The method according to claim 2, characterized in that, If the execution result is successful unlocking, a simulated door opening trigger signal is injected into the vehicle's onboard bus, including: Based on the first timestamp carried in the response message and the second timestamp of the response message received by the preset application interface, the start time of authorization effectiveness is determined; The signal injection time window is determined based on the authorization start time and the preset authorization validity period; Within the signal injection time window, the simulated door opening trigger signal is injected into the vehicle bus via the bus interface.

4. The method according to claim 3, characterized in that, The simulated door opening trigger signal includes a first message indicating that the remote authorization is effective and a second message indicating that the target door is opened; Before injecting the simulated door opening trigger signal into the vehicle bus via the bus interface, the method further includes: Obtain signal configuration parameters corresponding to the vehicle model identifier of the target vehicle, wherein the signal configuration parameters include a first definition rule corresponding to the first message and a second definition rule corresponding to the second message; Based on the first definition rule and the second definition rule, generate the first message and the second message that conform to the vehicle model identifier; The step of injecting the simulated door opening trigger signal into the vehicle bus via the bus interface includes: The first message and the second message are sequentially injected into the vehicle bus through the bus interface.

5. The method according to any one of claims 1 to 4, characterized in that, The multiple vehicle domains include the power domain, the vehicle infotainment domain, and the vehicle body domain; The step of acquiring the status response data of multiple vehicle domains in the target vehicle in response to the simulated door opening trigger signal includes: After the simulated door opening trigger signal is injected, a signal monitoring time window of a preset duration is started; Within the signal monitoring time window, a first monitoring data stream, a second monitoring data stream, and a third monitoring data stream are collected in parallel through a bus interface. The first monitoring data stream contains parameters characterizing the operating status of the power domain, the second monitoring data stream contains parameters characterizing the operating status of the vehicle infotainment domain, and the third monitoring data stream contains parameters characterizing the operating status of the vehicle body domain. The first monitoring data stream, the second monitoring data stream, and the third monitoring data stream are collectively used as the status response data.

6. The method according to claim 5, characterized in that, The determination of the vehicle wake-up test result of the target vehicle based on the state response data includes: Based on the first monitoring data stream, the second monitoring data stream, and the third monitoring data stream, determine whether the power domain, the vehicle infotainment domain, and the vehicle body domain meet their respective wake-up conditions; If the power domain, the vehicle infotainment domain, and the vehicle body domain all meet their respective wake-up conditions, then the vehicle wake-up test result is determined to be a successful wake-up; otherwise, the vehicle wake-up test result is determined to be a failed wake-up.

7. The method according to claim 6, characterized in that, The method further includes: If the vehicle wake-up test result is determined to be a wake-up failure, a rollback control signal is injected into the vehicle bus through the bus interface. The rollback control signal includes a third message for restoring the target door to a closed state and a fourth message for indicating remote authorization revocation.

8. A test terminal, characterized in that, include: The result acquisition unit is used to acquire the execution result of the target vehicle in response to the unlocking command, wherein the unlocking command is a command remotely sent from the mobile terminal to the target vehicle. A signal injection unit is used to inject a simulated door opening trigger signal into the vehicle bus of the target vehicle if the execution result is successful unlocking. The feedback acquisition unit is used to acquire the status response data fed back by multiple vehicle domains in the target vehicle in response to the simulated door opening trigger signal; The result determination unit is used to determine the whole vehicle wake-up test result of the target vehicle based on the state response data.

9. An electronic device, comprising: The memory and processor are characterized in that the processor, when executing a computer program stored in the memory, implements the steps of the vehicle wake-up test method based on a mobile terminal as described in any one of claims 1 to 7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the steps of the vehicle wake-up test method based on a mobile terminal as described in any one of claims 1 to 7.

Images