Vehicle remote power-on and power-off test method, system and device and storage medium

Abstract

The invention discloses a vehicle remote power-on and power-off test method, system and device and a storage medium, and the method comprises the steps: multiplexing a power-on process in an automatic parking data link based on an automatic test script deployed by a cloud management platform, so as to remotely control a vehicle to execute a power-on operation; in the process that the vehicle executes the power-on operation, key signals on a vehicle bus and vehicle state information displayed by an instrument are monitored in real time so as to carry out fault recognition; and uploading the identified fault, and executing a power-off operation after uploading. According to the application, the power-on and power-off test of the vehicle can be realized through remote control, on the basis of ensuring the test quantity, on-site labor cost is not needed, accurate fault identification can be realized, an automatic parking link is reused, vehicle-mounted original parts are not changed, external risks are not introduced, and extra cost brought by additional components is reduced.

Description

Technical Field

[0001] This invention relates to remote control of intelligent connected vehicles, and more particularly to a method, system, device, and storage medium for remote power-on / off testing of vehicles. Background Technology

[0002] With the rapid development of new energy vehicles, their functions and complexity are constantly increasing, placing higher demands on vehicle research and development and testing. Power-on / off testing is an indispensable part of the new energy vehicle R&D process, used to verify the working status and reliability of various systems during vehicle startup and shutdown. However, traditional power-on / off testing methods have the following limitations: 1. Low testing efficiency: Traditional testing methods mainly rely on manual operation, requiring testers to perform vehicle startup and shutdown operations on-site. This results in low testing efficiency and cannot be automated, making it difficult to meet the needs of large-scale testing. 2. High testing cost: Traditional testing methods require specialized testing equipment and personnel, leading to high testing costs and certain safety risks during the testing process. 3. Difficulty in reproducing test results: Traditional testing methods mainly rely on manual recording of test results, which is prone to errors or omissions, making the test results difficult to reproduce and affecting problem localization and analysis. 4. Limited testing scope: Traditional testing methods mainly target specific scenarios and cannot cover all possible power-on / off conditions, resulting in test results that cannot fully reflect the actual situation of the vehicle.

[0003] Therefore, how to fully reuse the original vehicle design functions without introducing potential external risks, and realize remote power-on / off testing, fault identification and automatic reporting functions, is a technical problem that urgently needs to be solved. Summary of the Invention

[0004] The main objective of this invention is to provide a method, system, device, and storage medium for remote power-on / off testing of vehicles. This invention enables remote control to perform power-on / off testing of vehicles, ensuring sufficient testing volume without requiring on-site manpower costs. It also enables accurate fault identification, reuses the automatic parking link, requires no modification to on-board components, does not introduce external risks, and reduces the additional costs associated with additional components.

[0005] In a first aspect, this application provides a method for remotely powering on / off testing of a vehicle, wherein the method includes the following steps: Based on the automated test scripts deployed on the cloud management platform, the power-on process in the automatic parking data link is reused to remotely control the vehicle to perform the power-on operation. During the power-on operation of the vehicle, key signals on the vehicle bus and vehicle status information displayed on the instrument panel are monitored in real time to identify faults. The identified faults are uploaded, and a power-off operation is performed after the upload.

[0006] In conjunction with the first aspect mentioned above, as an optional implementation method, the remote power-on / off automated test script can be embedded into the cloud management platform; In response to a remote power-on command from the cloud management platform or a mobile terminal communicating with it, a parking task request is generated and the parking task request is sent to the vehicle-mounted T-BOX; The vehicle-mounted T-BOX is used to parse the parking control command to intercept and execute the ready process in the automatic parking data link, wherein the ready process includes: The parking command is sent to the gateway controller to wake up the vehicle communication network; Perform the power-on operation for the high-voltage system; The vehicle controller or intelligent driving computing platform is used to control the vehicle to enter the Ready state and complete the remote power-on control.

[0007] In conjunction with the first aspect mentioned above, as an optional implementation method, a data acquisition device is used to monitor key signals on the vehicle bus in real time. The key signals include: ready status signal, BMS high voltage status information, MCU status self-test results, charging gun status, and vehicle speed. The system uses a camera to monitor the vehicle status information displayed on the dashboard, including: ready light, SOC level, fuel level, and various fault lights. Each signal value in the key signals is compared with the set normal value, and the vehicle status image displayed on the dashboard captured by the camera is compared with the fault-free reference image to identify the fault.

[0008] In conjunction with the first aspect mentioned above, as an optional implementation method, based on establishing a mapping relationship between key signals and fault codes, faults can be located by detecting fault codes in order to perform fault identification.

[0009] In conjunction with the first aspect mentioned above, as an optional implementation method, CAN bus data packets are intercepted at preset times before and after the time of the fault occurrence; Tag the CAN bus data packets, the tags including: fault type, fault level, timestamp, and test round; The tagged CAN bus data packets are uploaded to the fault database of the cloud management platform, and the vehicle is powered off after the upload.

[0010] In conjunction with the first aspect mentioned above, as an optional implementation method, the test rounds are determined based on the value of the loop counter to see if the preset number of tests is met. If the test cycle does not meet the preset number of times, the power-on / off process is repeated until the cycle counter value reaches the preset number of times, at which point the power-on / off test is terminated.

[0011] In conjunction with the first aspect mentioned above, as an optional implementation method, it is determined whether the preset sleep time is met; If the preset sleep time is not met, the power-on / off test will be performed after the preset sleep time is reached.

[0012] Secondly, this application provides a vehicle remote power-on / off testing system, the system comprising: A cloud management platform is used to deploy automated test scripts based on the cloud management platform, reuse the power-on process in the automatic parking data link, and remotely control the vehicle to perform power-on operations. An edge computing module is used to monitor key signals on the vehicle bus and vehicle status information displayed on the instrument panel in real time during the vehicle's power-on operation in order to identify faults. The identified faults are uploaded, and a power-off operation is performed after the upload.

[0013] Thirdly, this application also provides an electronic device, the electronic device comprising: a processor; and a memory storing computer-readable instructions, which, when executed by the processor, implement the method described in any one of the first aspects.

[0014] Fourthly, this application also provides a computer-readable storage medium storing computer program instructions that, when executed by a computer, cause the computer to perform the method described in any of the first aspects.

[0015] This application provides a method, system, device, and storage medium for remote vehicle power-on / off testing. The method includes the following steps: using an automated test script deployed on a cloud management platform, reusing the power-on process in the automatic parking data link to remotely control the vehicle to perform a power-on operation; during the vehicle's power-on operation, real-time monitoring of key signals on the vehicle bus and vehicle status information displayed on the instrument panel for fault identification; uploading the identified faults, and then performing a power-off operation after uploading. This application enables remote control for vehicle power-on / off testing, ensuring sufficient testing volume without requiring on-site manpower costs, achieving accurate fault identification, reusing the automatic parking link without modifying onboard components, avoiding external risks, and reducing the additional costs associated with add-on components.

[0016] It should be understood that the above general description and the following detailed description are merely exemplary and do not limit the invention. Attached Figure Description

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

[0018] Figure 1 This is a flowchart of a vehicle remote power-on / off testing method provided in the embodiments of this application; Figure 2 This is a schematic diagram of a vehicle remote power-on / off testing system provided in an embodiment of this application; Figure 3 This is a schematic diagram of a vehicle remote power-on / off test provided in an embodiment of this application; Figure 4 This is a schematic diagram of an electronic device provided in an embodiment of this application; Figure 5 This is a schematic diagram of a computer-readable program medium provided in an embodiment of this application. Detailed Implementation

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

[0020] Furthermore, the accompanying drawings are merely illustrative of this disclosure and are not necessarily drawn to scale. Some of the block diagrams shown in the drawings represent functional entities and do not necessarily correspond to physically or logically independent entities.

[0021] Reference Figure 1 , Figure 1 The diagram shown is a flowchart of a remote power-on / off testing method for vehicles provided by the present invention. Figure 1 As shown, the method includes the following steps: Step S101: Based on the automated test script deployed on the cloud management platform, reuse the power-on process in the automatic parking data link to remotely control the vehicle to perform the power-on operation.

[0022] Specifically, remote power-on / off automated test scripts will be embedded into the cloud management platform; In response to a remote power-on command from the cloud management platform or a mobile terminal communicating with it, a parking task request is generated and the parking task request is sent to the vehicle-mounted T-BOX; The vehicle-mounted T-BOX is used to parse the parking control command to intercept and execute the ready process in the automatic parking data link, wherein the ready process includes: The parking command is sent to the gateway controller to wake up the vehicle communication network; Perform the power-on operation for the high-voltage system; The vehicle controller or intelligent driving computing platform is used to control the vehicle to enter the Ready state and complete the remote power-on control.

[0023] Understandably, the remote power-on / off script is embedded into the cloud management platform. Remote power-on involves: issuing a task via an app / cloud platform, reusing the automatic parking data link, and remotely issuing a parking task (not complete, only capturing and executing the "ready" part) via T-BOX. This executes gateway activation and high-voltage connection operations, followed by an MDC sending a "ready" request to complete the remote power-on. For easier understanding, an example is provided: an automated script capable of simulating remote start and stop is written and deployed to a cloud-based management system.

[0024] The cloud platform issues a pseudo-parking task, intended to intercept some parking functions, not to actually park the vehicle. The command is received via the T-BOX (vehicle communication module, responsible for the vehicle's connection to the external network). The T-BOX transmits the command to the gateway (the information hub of the vehicle's internal network), which wakes up the relevant controllers. The vehicle performs a high-voltage power connection operation (for electric vehicles, this is a prerequisite for the power system to operate). The MDC (vehicle computing platform) confirms the system is normal and sends a Ready signal, at which point the vehicle enters a state similar to starting up and ready to shift gears and drive.

[0025] Step S102: During the power-on operation of the vehicle, key signals on the vehicle bus and vehicle status information displayed on the instrument panel are monitored in real time to identify faults.

[0026] Specifically, a data acquisition device is used to monitor key signals on the vehicle bus in real time. These key signals include: ready status signal, BMS high voltage status information, MCU status self-test results, charging gun status, and vehicle speed. The system uses a camera to monitor the vehicle status information displayed on the dashboard, including: ready light, SOC level, fuel level, and various fault lights. Each signal value in the key signals is compared with a set normal value, and the vehicle status image displayed on the dashboard captured by the camera is compared with a fault-free reference image to identify faults. Alternatively, a mapping relationship between key signals and fault codes can be established to locate faults through detected fault codes, thus enabling key signal fault identification.

[0027] Understandably, the data acquisition unit, acting as an edge computing module, monitors key signals in real time. Simultaneously, an external camera monitors the instrument panel's fault lights and critical information such as SOC and fuel level. A visual recognition algorithm is embedded in the data acquisition unit to compare camera images. When a specific fault is identified, the data is packetized, tagged, and uploaded.

[0028] To illustrate, as an edge computing device, the data acquisition unit can directly read various signals (such as battery voltage, motor speed, fault codes, etc.) from the vehicle's CAN bus and other networks in real time. It can quickly analyze data locally instead of transmitting all data to the cloud, resulting in faster response times. The vehicle's dashboard is monitored in real time using a camera. This provides a dual guarantee: monitoring the dashboard via the CAN bus and a camera to identify faults. The data acquisition unit incorporates image recognition algorithms to analyze the camera footage in real time, identifying: fault lights: whether any warning lights that shouldn't be illuminated (such as engine fault, battery fault, etc.) are lit; and key information: whether SOC (battery charge) and fuel level (in hybrid models) are within normal ranges.

[0029] Step S103: Upload the identified fault and then perform a power-down operation.

[0030] Specifically, it involves intercepting CAN bus data packets at preset times before and after the fault occurs. Tag the CAN bus data packets, the tags including: fault type, fault level, timestamp, and test round; The tagged CAN bus data packets are uploaded to the fault database of the cloud management platform, and the vehicle is powered off after the upload.

[0031] Understandably, when the data acquisition device detects a pre-defined fault through data signal or image recognition, it will act immediately: 1. Only extract key data for a period before and after the fault occurs, rather than all data, to save bandwidth and storage. 2. Tagging: Label this data with a fault tag, noting the fault type, occurrence time, etc. 3. Uploading: Upload these processed evidence packages to the cloud for engineers to analyze, and then the cloud management platform will control the vehicle to shut down.

[0032] In one embodiment, after a power-down operation, based on the value of a loop counter, it is determined whether the preset number of test cycles has been met. If the preset number of test cycles has not been met, the power-up / down process is repeated until the loop counter value reaches the preset number, at which point the power-up / down test is terminated. This can be understood as setting a total number of tests (e.g., 5000 times). The power-up / down process will continue to repeat until the set number is reached, at which point it will automatically stop. In other words, by performing hundreds or thousands of repeated power-up / down operations, the vehicle's power management system, related controllers, and software are stress-tested, exposing potential defects or durability issues that might not appear in a single or a few tests.

[0033] Reference Figure 2 , Figure 2 The diagram shown is a schematic of a vehicle remote power-on / off testing system provided by the present invention. Figure 2 As shown, the system includes: Cloud Management Platform 201: It is used to deploy automated test scripts based on the cloud management platform, reuse the power-on process in the automatic parking data link, and remotely control the vehicle to perform power-on operations.

[0034] Edge computing module 202: It is used to monitor key signals on the vehicle bus and vehicle status information displayed on the instrument panel in real time during the power-on operation of the vehicle, so as to identify faults. The identified faults are uploaded, and a power-off operation is performed after the upload.

[0035] Furthermore, in one possible implementation, a processing module is used to embed remote power-on / off automated test scripts into a cloud management platform. A cloud management platform is used to generate a parking task request in response to a remote power-on command from the cloud management platform or a mobile terminal communicating with it, and to send the parking task request to the vehicle-mounted T-BOX. The vehicle-mounted T-BOX is used to parse the parking control command to intercept and execute the ready process in the automatic parking data link, wherein the ready process includes: The parking command is sent to the gateway controller to wake up the vehicle communication network; Perform the power-on operation for the high-voltage system; The vehicle controller or intelligent driving computing platform is used to control the vehicle to enter the Ready state and complete the remote power-on control.

[0036] Furthermore, in one possible implementation, the edge computing module is also used to monitor key signals on the vehicle bus in real time using a data acquisition device. The key signals include: ready status signal, BMS high voltage status information, MCU status self-test result, charging gun status, and vehicle speed. The system uses a camera to monitor the vehicle status information displayed on the dashboard, including: ready light, SOC level, fuel level, and various fault lights. Each signal value in the key signals is compared with the set normal value, and the vehicle status image displayed on the dashboard captured by the camera is compared with the fault-free reference image to identify the fault.

[0037] Furthermore, in one possible implementation, the edge computing module is also used to locate faults by detecting fault codes based on the established mapping relationship between key signals and fault codes, so as to perform fault identification.

[0038] Furthermore, in one possible implementation, the edge computing module is also used to intercept CAN bus data packets before and after a preset time before the fault occurs. Tag the CAN bus data packets, the tags including: fault type, fault level, timestamp, and test round; The tagged CAN bus data packets are uploaded to the fault database of the cloud management platform, and the vehicle is powered off after the upload.

[0039] Furthermore, in one possible implementation, the cloud management platform is also used to determine whether the number of test rounds meets the preset number based on the value of the loop counter; If the test cycle does not meet the preset number of times, the power-on / off process is repeated until the cycle counter value reaches the preset number of times, at which point the power-on / off test is terminated.

[0040] Furthermore, in one possible implementation, the cloud management platform is also used to determine whether a preset sleep time has been met; If the preset sleep time is not met, the power-on / off test will be performed after the preset sleep time is reached.

[0041] Reference Figure 3 , Figure 3 The diagram shown is a schematic diagram of a vehicle remote power-on / off test provided by the present invention. Figure 3 As shown: The remote power-on / off script is embedded into the cloud management platform.

[0042] The task is issued via app / cloud platform, reusing the automatic parking data link. The parking task is remotely issued via T-BOX (not complete, only the process of getting ready is captured and executed), the gateway is pulled up and the high voltage is connected. Then the MDC sends a ready request to complete the remote power-on.

[0043] A data acquisition unit serves as an edge computing module to monitor key signals in real time. Simultaneously, an external camera monitors the instrument panel's fault lights and key information such as SOC and fuel level. A visual recognition algorithm is embedded in the data acquisition unit to compare camera images. When a specific fault is identified, the data is packaged, tagged, and uploaded.

[0044] If the set number of test rounds has not been reached, repeat the above operation until the set number of tests is completed, then terminate the test.

[0045] To illustrate this in a simple way, the test objective is to verify the stability of the vehicle gateway and battery management system of a new type A electric SUV during 5000 remote start cycles.

[0046] A data acquisition unit was installed inside the vehicle and connected to the vehicle's CAN bus.

[0047] The automated scripts for powering on and off were uploaded to the cloud platform.

[0048] The first iteration "" The cloud platform sends a command to the vehicle's T-BOX: "Please execute the automatic parking preparation process."

[0049] Upon receiving the command, the T-BOX wakes up the relevant controllers (such as VCU, BMS, MDC, etc.) through the gateway. The vehicle performs a high-voltage connection operation, activating the high-voltage circuit of the battery pack. After the MDC self-test is successful, it sends a "Ready" signal to the vehicle, and the instrument panel displays "Vehicle Ready" or a similar READY indicator light. At this point, the vehicle's status is equivalent to when you get in the car, press the brake pedal, and press the start button.

[0050] Fault monitoring: The data acquisition instrument monitored the CAN bus and found no fault codes. All voltage and temperature signals were within the normal range.

[0051] Visual monitoring: The camera captures an image of the dashboard, and the recognition algorithm confirms that the READY light is on, there are no fault light alarms, and the SOC is displayed as 85%.

[0052] Result: No faults, the system did not trigger any operations. After the vehicle remained in a ready state for 30 seconds, the cloud platform automatically issued a power-off command, and the vehicle shut down.

[0053] Nth iteration: Assume the test has reached the 1523rd cycle. Remote power-on is performed, following the same procedure. The vehicle is remotely started again. Fault monitoring detects the fault. The data acquisition unit captures a clear fault code from the battery manager on the CAN bus: BMS_123: High-voltage contactor sticking fault.

[0054] Visual monitoring: The camera captures the dashboard, and the image recognition algorithm identifies the red "battery fault light" as illuminated. Intelligent processing by the data acquisition unit: Data packetization: The data acquisition unit acts immediately. Instead of storing all the data for the entire day, it extracts the bus data from 30 seconds before the fault occurred (during the vehicle's high-voltage process) and 10 seconds after, packaging it into a data segment of approximately 40 seconds. Tagging: It tags this data packet with: [Fault Code: BMS_123][Severity Level: High][Loop Count: 1523][Timestamp: 2023-10-27 10:15:30][Trigger Source: Data + Vision]. Upload: Through a 4G / 5G network, this tagged and refined data packet is uploaded to the fault analysis database in the cloud.

[0055] Upon receiving the alarm, the cloud platform automatically paused the test and immediately sent emails and SMS messages to the test engineers. The engineers downloaded the data package and analyzed the high-voltage contactor's status data during the 1523rd cycle, thus pinpointing the root cause of the problem—likely a software bug in the contactor drive circuit that was triggered under specific conditions.

[0056] 5000th loop - Test complete. The system completed 5000 loops as planned.

[0057] Three different faults were detected during the test, all of which were recorded and reported. The test automatically terminated, generating a final test report, including the total number of tests, success rate, and fault list.

[0058] The following reference Figure 4 To describe an electronic device 400 according to this embodiment of the present invention. Figure 4 The electronic device 400 shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of the present invention.

[0059] like Figure 4 As shown, the electronic device 400 is manifested in the form of a general-purpose computing device. The components of the electronic device 400 may include, but are not limited to: at least one processing unit 410, at least one storage unit 420, and a bus 430 connecting different system components (including storage unit 420 and processing unit 410).

[0060] The storage unit stores program code that can be executed by the processing unit 410, causing the processing unit 410 to perform the steps described in the "Embodiment Methods" section of this specification according to various exemplary embodiments of the present invention.

[0061] Storage unit 420 may include readable media in the form of volatile storage units, such as random access memory (RAM) 421 and / or cache memory 422, and may further include read-only memory (ROM) 423.

[0062] Storage unit 420 may also include a program / utility 424 having a set (at least one) of program modules 425, including but not limited to: an operating system, one or more application programs, other program modules, and program data, each or some combination of these examples may include an implementation of a network environment.

[0063] Bus 430 can represent one or more of several types of bus structures, including a memory cell bus or memory cell controller, a peripheral bus, a graphics acceleration port, a processing unit, or a local bus using any of the various bus structures.

[0064] Electronic device 400 can also communicate with one or more external devices (e.g., keyboard, pointing device, Bluetooth device, etc.), one or more devices that enable a user to interact with electronic device 400, and / or any device that enables electronic device 400 to communicate with one or more other computing devices (e.g., router, modem, etc.). This communication can be performed via input / output (I / O) interface 450. Furthermore, electronic device 400 can also communicate with one or more networks (e.g., local area network (LAN), wide area network (WAN), and / or public networks, such as the Internet) via network adapter 460. As shown, network adapter 460 communicates with other modules of electronic device 400 via bus 430. It should be understood that, although not shown in the figures, other hardware and / or software modules can be used in conjunction with electronic device 400, including but not limited to: microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data backup storage systems.

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

[0066] According to the present disclosure, a computer-readable storage medium is also provided, on which a program product capable of implementing the methods described above is stored. In some possible embodiments, various aspects of the present invention can also be implemented as a program product comprising program code that, when the program product is run on a terminal device, causes the terminal device to perform the steps of the various exemplary embodiments of the present invention described in the "Exemplary Methods" section above.

[0067] refer to Figure 5 As shown, a program product 500 for implementing the above-described method according to an embodiment of the present invention is described. It may employ a portable compact disc read-only memory (CD-ROM) and include program code, and may run on a terminal device, such as a personal computer. However, the program product of the present invention is not limited thereto. In this document, the readable storage medium may be any tangible medium containing or storing a program that may be used by or in conjunction with an instruction execution system, apparatus, or device.

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

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

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

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

[0072] Furthermore, the above figures are merely illustrative of the processes included in the method according to exemplary embodiments of the present invention, and are not intended to be limiting. It is readily understood that the processes shown in the above figures do not indicate or limit the temporal order of these processes. Additionally, it is readily understood that these processes may be executed synchronously or asynchronously, for example, in multiple modules.

[0073] The above description is merely a specific embodiment of this application, enabling those skilled in the art to understand or implement this application. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of this application. Therefore, this application is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features claimed herein.

[0074] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

Claims

1. A vehicle remote power up and down test method, characterized by, The application comprises the following steps: An automatic test script based on a cloud management platform is deployed to reuse the power-on process in an automatic parking data link to remotely control the vehicle to perform a power-on operation; During the process of the vehicle performing the power-on operation, key signals on the vehicle bus and vehicle state information displayed on the instrument panel are monitored in real time to identify faults; The identified faults are uploaded, and after uploading, a power-off operation is performed.

2. The method of claim 1, wherein, The automatic test script based on the cloud management platform is deployed to reuse the power-on process in the automatic parking data link to remotely control the vehicle to perform a power-on operation, which comprises the following steps: An automatic test script for remote power-on and power-off is implanted in the cloud management platform; In response to a remote power-on instruction from the cloud management platform or a mobile terminal in communication with the cloud management platform, a parking task request is generated and sent to the vehicle-mounted T-BOX; The parking control instruction is parsed by the vehicle-mounted T-BOX to intercept and execute the power-on process in the automatic parking data link, wherein the power-on process comprises the following steps: A parking instruction is sent to the gateway controller to wake up the entire vehicle communication network; A high-voltage system power-on operation is performed; The vehicle is controlled by the vehicle controller or the intelligent driving computing platform to enter the power-on ready state, completing remote power-on control.

3. The method of claim 1, wherein, The key signals on the vehicle bus and the vehicle state information displayed on the instrument panel are monitored in real time to identify faults, which comprises the following steps: Key signals on the vehicle bus are monitored in real time by a data acquisition instrument, including: ready state signal, BMS high-voltage state information, MCU state self-checking result, charging gun state, and vehicle speed; The vehicle state information displayed on the instrument panel is monitored by a camera, including: ready light, SOC amount, oil amount, and various fault lights; Each signal value in the key signals is compared with the set normal value, and the vehicle state image displayed on the instrument panel captured by the camera is compared with the fault-free reference image to identify faults.

4. The method of claim 3, wherein, The application comprises the following steps: Based on the mapping relationship between key signals and fault codes, the fault is located by detecting the fault code to identify faults.

5. The method of claim 1, wherein, The identified faults are uploaded, and after uploading, a power-off operation is performed, which comprises the following steps: CAN bus data packets within a preset time before and after the occurrence of the fault are intercepted; The CAN bus data packets are labeled, including: fault type, fault level, timestamp, and test round; The labeled CAN bus data packets are uploaded to the fault database of the cloud management platform, and after uploading, the vehicle is controlled to power off.

6. The method of claim 1, wherein, After the identified faults are uploaded and the vehicle is powered off after uploading, the following steps are included: Based on the cycle counter value, it is determined whether the test round meets the preset number of times; If it is determined that the test round does not meet the preset number of times, the power-on and power-off process is repeated until the cycle counter value reaches the preset number of times, and the power-on and power-off test is terminated.

7. The method of claim 6, wherein, After it is determined that the test round does not meet the preset number of times, the following steps are included: It is determined whether the preset sleep time is met; If the preset sleep time is not met, the power-on and power-off test is performed after the preset sleep time is reached.

8. A vehicle remote power up / down test system, characterized by, The application comprises the following steps: A cloud management platform is configured to reuse a power-on process in an automatic parking data link to remotely control a vehicle to perform a power-on operation based on an automatic test script deployed by the cloud management platform; An edge computing module is configured to monitor key signals on a vehicle bus and vehicle state information displayed by instruments in real time during the power-on operation of the vehicle to identify faults; The identified faults are uploaded and a power-off operation is performed after the uploading.

9. An electronic device, comprising: The electronic device comprises: a processor; a memory having computer readable instructions stored thereon, the computer readable instructions, when executed by the processor, implement the method of any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer program instructions stored therein, when executed by a computer, cause the computer to perform the method of any one of claims 1 to 7.

Images