Verification method, vehicle and apparatus

Abstract

Provided in the present application are a verification method, a vehicle and an apparatus. The method comprises: receiving a first verification task and a first test file, the first verification task being used to instruct the verification of an OTA function, and the first test file comprising only a driver file; on the basis of the first verification task, performing verification on a first node to obtain a first verification result, the first verification result being used to indicate the use status of the first node; and sending the first verification result. The present application can be applied to a variety of scenarios such as vehicle production line testing, 4S dealership maintenance and inspection, and user self-testing, saves the time for verifying the completeness of the OTA function, and helps to ensure the normal upgrade of vehicles.

Description

A testing method, vehicle, and apparatus Technical Field

[0001] This application relates to the field of intelligent vehicles, and more specifically, to a testing method and apparatus. Background Technology

[0002] Continuous software iteration and updates are crucial for optimizing product functionality and ensuring user experience. For example, in the field of intelligent vehicles, vehicle manufacturers can use over-the-air (OTA) updates to remotely update software. With the increasing prevalence of OTA functionality, its proper functioning is a key factor in ensuring a positive user experience.

[0003] However, methods for testing OTA functionality are often inefficient, so finding efficient testing methods has become an urgent problem to be solved. Summary of the Invention

[0004] This application provides a testing method, vehicle, and apparatus. It enables rapid testing of a vehicle's over-the-air (OTA) functionality.

[0005] In a first aspect, a verification method is provided, the method comprising: receiving a first verification task and a first test file, the first verification task being used to instruct the verification of OTA function, the first test file containing only driver files; performing a verification of a first node based on the first verification task to obtain a first verification result, the first verification result being used to indicate the usage status of the first node; and sending the first verification result.

[0006] Based on the above technical solution, the size of the first test file can be reduced, thereby reducing the download and installation time of the test file during the OTA function testing process, thus effectively improving the efficiency of OTA function testing.

[0007] In one possible implementation, the first node can install a first test file. Since the first test file only contains driver files, it is relatively small, allowing the installation process to be completed more quickly and effectively shortening the installation time.

[0008] In another possible implementation, the first node may not need to install the first test file; instead, only the verification of the first node itself can be performed. This simplifies the installation process, allowing for faster verification of OTA functionality.

[0009] In conjunction with the first aspect, in some implementations of the first aspect, the method further includes: when the first node has one or more subordinate nodes, sending a first verification task and a first test file to one or more subordinate nodes; receiving a second verification result sent by one or more subordinate nodes, the second verification result being used to indicate the usage status of one or more subordinate nodes; and sending the second verification result.

[0010] In one possible implementation, the slave nodes of the master node remain the master node.

[0011] In another possible implementation, the slave nodes of the master node can be non-master nodes.

[0012] In addition, a slave node of a non-master node can also be a non-master node.

[0013] Based on the above technical solution, by sending inspection tasks and test files to one or more subordinate nodes, comprehensive inspection of multiple nodes can be achieved, which helps to ensure the integrity of the OTA function of all nodes.

[0014] In conjunction with the first aspect, in some implementations of the first aspect, one or more subordinate nodes include a first subordinate node, which is a non-master node, and receive a second verification result sent by one or more subordinate nodes, including: receiving a second verification result sent by the first subordinate node when the first subordinate node has completed the installation of the first test file.

[0015] For example, due to limited capabilities, non-master nodes need to wait until the driver files in the first test file are installed before providing the test results.

[0016] Based on the above technical solution, a targeted OTA function testing method can be provided for non-master nodes, thereby enabling faster OTA function testing.

[0017] In conjunction with the first aspect, in some implementations of the first aspect, the method further includes: sending a flash diagnostic command to the first slave node, the flash diagnostic command being used to instruct the first slave node to install the first test file.

[0018] Based on the above technical solution, the installation action of the first slave node can be precisely controlled, which helps the first test file to be correctly installed into the first slave node.

[0019] In conjunction with the first aspect, in some implementations of the first aspect, sending a first verification task and a first test file to one or more slave nodes includes: sending the first test file to the random access memory (RAM) of the first slave node.

[0020] Based on the above technical solution, the original driver file of the first slave node can be protected from interference by OTA function testing, thereby improving the storage security of the first slave node. For example, it will not affect the driver file in the read-only memory (ROM).

[0021] In conjunction with the first aspect, in some implementations of the first aspect, the first subordinate node adopts an embedded storage method.

[0022] In conjunction with the first aspect, in some implementations of the first aspect, before receiving the second verification result sent by the first slave node, the method further includes: determining a first value based on the first test file and the first file integrity key, the first value being used to verify the second file integrity key in the first slave node; sending the first value to the first slave node; wherein receiving the second verification result sent by the first slave node includes: receiving the verification result for the second file integrity key sent by the first slave node.

[0023] Based on the above technical solution, it is helpful to quickly verify the accuracy of the file integrity key of non-master node.

[0024] In conjunction with the first aspect, in some implementations of the first aspect, the method further includes: receiving a first upgrade file when the first verification result indicates that the first node is in a normal state of use, and the second verification result indicates that one or more subordinate nodes are in a normal state of use, the first upgrade file being used for upgrading the first node and at least some of the one or more subordinate nodes.

[0025] Based on the above technical solution, by checking whether the status of each node is normal before upgrading, it helps to avoid the risk of upgrade failure or vehicle malfunction due to problems with the nodes during the upgrade, effectively improving the success rate of OTA upgrades and enhancing the user experience.

[0026] In conjunction with the first aspect, in some implementations of the first aspect, receiving the first inspection task and the first test file includes: receiving the first inspection task and the first test file from a cloud server.

[0027] Based on the above technical solutions, the OTA function testing can be uniformly managed and updated through cloud servers, improving the flexibility and timeliness of testing. It can also be applied to the large-scale, dynamic operation and maintenance needs of intelligent connected vehicles.

[0028] Secondly, a verification method is provided, the method comprising: receiving a first verification task and a first test file, the first verification task being used to instruct the verification of OTA function, the first test file containing only driver files; performing a verification of a first slave node based on the first verification task to obtain a second verification result, the second verification result being used to indicate the usage status of the first slave node; and sending the second verification result.

[0029] In conjunction with the second aspect, in some implementations of the second aspect, the first slave node is a non-master node, and the second verification result is sent, including: sending the second verification result when the first slave node has completed the installation of the first test file.

[0030] In conjunction with the second aspect, in some implementations of the second aspect, the method further includes: receiving a flash diagnostic command, the flash diagnostic command being used to instruct the first slave node to install the first test file.

[0031] In conjunction with the second aspect, in some implementations of the second aspect, receiving the first verification task and the first test file includes: the random access memory (RAM) of the first slave node receiving the first test file.

[0032] In conjunction with the second aspect, in some implementations of the second aspect, the first subordinate node adopts an embedded storage method.

[0033] In conjunction with the second aspect, in some implementations of the second aspect, the method further includes: receiving a first value, the first value being used to verify a second file integrity key in a first subordinate node; determining a second value based on a first test file and the first file integrity key; and determining a verification result of the second file integrity key based on the first value and the second value, the second verification result including the verification result of the second file integrity key.

[0034] Thirdly, a verification method is provided, which includes: sending a first verification task and a first test file to a vehicle, wherein the first verification task is used to instruct the verification of the OTA function and the first test file contains only driver files; and receiving a third verification result, wherein the third verification result is used to indicate the usage status of one or more nodes in the vehicle.

[0035] In conjunction with the third aspect, in some implementations of the third aspect, the method further includes: receiving a fourth verification result, which is used to indicate the usage status of one or more subordinate nodes of a node.

[0036] In conjunction with the third aspect, in some implementations of the third aspect, the method further includes: when the third verification result indicates that the usage status of one or more nodes is normal, and the fourth verification result indicates that the usage status of the subordinate node is normal, sending a first upgrade file, the first upgrade file being used for upgrading one or more nodes and at least some of the subordinate nodes.

[0037] Fourthly, a testing apparatus is provided, comprising: a receiving unit for receiving a first testing task and a first test file, wherein the first testing task is used to instruct the testing of OTA functionality, and the first test file contains only driver files; an execution unit for performing a test on a first node based on the first testing task to obtain a first testing result, wherein the first testing result is used to indicate the usage status of the first node; and a sending unit for sending the first testing result.

[0038] In conjunction with the fourth aspect, in some implementations of the fourth aspect, the sending unit is further configured to: send a first inspection task and a first test file to one or more subordinate nodes when the first node has one or more subordinate nodes; the receiving unit is further configured to: receive a second inspection result sent by one or more subordinate nodes, the second inspection result being used to indicate the usage status of one or more subordinate nodes; the sending unit is further configured to: send the second inspection result.

[0039] In conjunction with the fourth aspect, in some implementations of the fourth aspect, one or more subordinate nodes include a first subordinate node, which is a non-master node. The receiving unit is further configured to: receive a second verification result sent by the first subordinate node when the first subordinate node completes the installation of the first test file.

[0040] In conjunction with the fourth aspect, in some implementations of the fourth aspect, the sending unit is also used to: send a flash diagnostic command to the first slave node, the flash diagnostic command being used to instruct the first slave node to install the first test file.

[0041] In conjunction with the fourth aspect, in some implementations of the fourth aspect, the sending unit is also used to: send the first test file to the random access memory (RAM) of the first slave node.

[0042] In conjunction with the fourth aspect, in some implementations of the fourth aspect, the first subordinate node adopts an embedded storage method.

[0043] In conjunction with the fourth aspect, in some implementations of the fourth aspect, the apparatus further includes a determining unit, configured to: determine a first value based on a first test file and a first file integrity key, the first value being used to verify a second file integrity key in a first subordinate node; a sending unit, further configured to: send the first value to the first subordinate node; and a receiving unit, further configured to: receive the verification result for the second file integrity key sent by the first subordinate node.

[0044] In conjunction with the fourth aspect, in some implementations of the fourth aspect, the receiving unit is further configured to: receive a first upgrade file when the first verification result indicates that the first node is in a normal state of use, and the second verification result indicates that one or more subordinate nodes are in a normal state of use, the first upgrade file being used for upgrading the first node and at least some of the one or more subordinate nodes.

[0045] In conjunction with the fourth aspect, in some implementations of the fourth aspect, the receiving unit is also used to: receive the first verification task and the first test file from the cloud server.

[0046] Fifthly, an inspection apparatus is provided, comprising: a memory for storing a computer program; and a processor for executing the computer program stored in the memory, such that the apparatus performs any one of the methods of the first aspect, the second aspect, or the third aspect.

[0047] Sixthly, a vehicle is provided that includes any one of the possible devices of the fourth or fifth aspect.

[0048] In a seventh aspect, a computer-readable storage medium is provided having instructions stored thereon, which, when executed by a processor, cause the processor to implement any one of the possible methods of the first aspect, the second aspect, or the third aspect.

[0049] Eighthly, a computer program product is provided, including computer program code, which, when run on a computer, enables the computer to implement any one of the possible methods of the first, second, or third aspects.

[0050] Ninth aspect, a chip is provided, the chip including circuitry for performing any one of the possible methods of the first aspect, the second aspect, or the third aspect. Attached Figure Description

[0051] Figure 1 is a functional block diagram of a vehicle 100 provided in an embodiment of this application.

[0052] Figure 2 is a schematic diagram of a distributed electrical / electronic (E / E) architecture.

[0053] Figure 3 is a schematic diagram of a domain-centralized E / E architecture.

[0054] Figure 4 is a schematic diagram of a centralized E / E architecture.

[0055] Figure 5 is a schematic flowchart of a complete OTA upgrade method 500.

[0056] Figure 6 is a schematic flowchart of a software installation method 600.

[0057] Figure 7 is a schematic flowchart of an inspection method 700 provided in an embodiment of this application.

[0058] Figure 8 is a schematic flowchart of a verification method 800 for a master control node provided in an embodiment of this application.

[0059] Figure 9 is a schematic flowchart of a verification method 900 for non-master nodes provided in an embodiment of this application.

[0060] Figure 10 is a schematic diagram of an architecture including a proxy node provided in an embodiment of this application.

[0061] Figure 11 is a schematic diagram of another architecture including a proxy node provided in an embodiment of this application.

[0062] Figure 12 is a schematic flowchart of an OTA function verification method 1200 provided in an embodiment of this application.

[0063] Figure 13 is a schematic diagram of a vehicle factory inspection scenario provided in an embodiment of this application.

[0064] Figure 14 is a schematic diagram of a 4S store inspection scenario provided in an embodiment of this application.

[0065] Figure 15 is a schematic diagram of a user self-test scenario provided in an embodiment of this application.

[0066] Figures 16-20 are a set of graphical user interfaces (GUIs) that provide prompts to users according to embodiments of this application.

[0067] Figure 21 is a schematic diagram of another user self-test scenario provided in an embodiment of this application.

[0068] Figures 22-26 show another set of GUI prompts for the user provided in the embodiments of this application.

[0069] Figure 27 is a schematic block diagram of an inspection device 2700 provided in an embodiment of this application. Detailed Implementation

[0070] The technical solutions in this application will now be described with reference to the accompanying drawings.

[0071] The technical solutions of the embodiments of this application will be described below with reference to the accompanying drawings. In the description of the embodiments of this application, unless otherwise stated, " / " means "or," for example, A / B can mean A or B; "and / or" in this document is merely a description of the association relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. "At least one" refers to one or more. For example, "at least one of A and B," similar to "A and / or B," describes the association relationship between related objects, indicating that three relationships can exist. For example, at least one of A and B can represent: A existing alone, A and B existing simultaneously, and B existing alone.

[0072] The prefixes such as "first" and "second" used in this application embodiment are merely for distinguishing different descriptive objects and do not limit the position, order, priority, quantity, or content of the described objects. The use of ordinal numbers and other prefixes used to distinguish descriptive objects in this application embodiment does not constitute a limitation on the described objects. The description of the described objects is given in the claims or the context of the embodiments, and should not constitute unnecessary restrictions due to the use of such prefixes. Furthermore, in the description of this embodiment, unless otherwise stated, "multiple" means two or more.

[0073] Figure 1 is a functional block diagram of a vehicle 100 provided in an embodiment of this application. The vehicle 100 may include a sensing system 110, a computing platform 120, and a display device 130.

[0074] Some or all of the functions of vehicle 100 can be controlled by computing platform 120. Computing platform 120 may include one or more processors, such as processors 121 to 12n (n being a positive integer). A processor is a circuit with signal processing capabilities. In one implementation, the processor can be a circuit with instruction read and execute capabilities, such as a central processing unit (CPU), microprocessor, graphics processing unit (GPU) (which can be understood as a type of microprocessor), or digital signal processor (DSP). In another implementation, the processor can implement certain functions through the logical relationships of hardware circuits. These logical relationships are fixed or reconfigurable. For example, the processor may be a hardware circuit implemented using an application-specific integrated circuit (ASIC) or a programmable logic device (PLD), such as a field-programmable gate array (FPGA). In reconfigurable hardware circuits, the process of the processor loading a configuration document and configuring the hardware circuit can be understood as the process of the processor loading instructions to implement some or all of the functions of the aforementioned units. Furthermore, the processor can also be a hardware circuit designed for artificial intelligence, which can be understood as an ASIC, such as a neural network processing unit (NPU), tensor processing unit (TPU), deep learning processing unit (DPU), etc. In addition, the computing platform 120 may also include a memory for storing instructions. Some or all of the processors 121 to 12n can call the instructions in the memory to implement the corresponding functions.

[0075] The in-cabin display devices 130 are mainly divided into two categories: the first is an in-vehicle display screen; the second is a projection display screen, such as a head-up display (HUD). It should be noted that the display device 130 involved in the embodiments of this application is not limited to these. For example, the display device 130 can also be a light display screen or a projection screen.

[0076] Optionally, the structure of the vehicle 100 described above is merely illustrative. In actual applications, various components of the vehicle 100 may be added or removed as needed.

[0077] In order to accurately describe the technical content of this application and to accurately understand the content of this application, before describing the specific embodiments, the terms used in this specification are explained or defined as follows.

[0078] OTA: OTA is a method of remotely updating device firmware or software through wireless communication networks (such as Wi-Fi, cellular networks, etc.). It is widely used in modern IoT devices, smartphones, smart cars, etc., and provides a convenient update method without physical connection.

[0079] Firmware: Firmware is software embedded in a hardware device and can be stored in read-only memory (ROM) or flash memory. It is responsible for controlling the basic functions of the hardware, such as initialization, configuration, diagnostics, and operation of hardware components. Firmware can be upgraded to add new features, fix bugs, or improve performance.

[0080] Electronic Control Unit (ECU): The ECU is the core component of a vehicle, a collective term for electronic devices in a car used to control, manage, and execute specific functions. Different ECUs control different functions. For example, the engine control module (ECM) is responsible for controlling the engine's combustion process, fuel injection, ignition timing, etc.; the transmission control unit (TCU) is responsible for controlling the automatic transmission's shift logic, gear ratios, and transmission oil pressure; and the air conditioning temperature control (ATC) unit is responsible for managing and regulating the temperature and airflow of the vehicle's air conditioning system. The ECU may contain firmware, which guides the ECU in managing and controlling hardware devices.

[0081] Key: A key can be a special code or digital sequence written into the ECU's storage to ensure secure communication and data protection between the ECU and other parts of the vehicle. Examples of keys include secure access keys, file integrity keys, etc.

[0082] Secure Access Key: A secure access key is a key used to verify and authorize access to the ECU. This key can be pre-set by the vehicle manufacturer and enables authorized personnel or equipment to communicate with the ECU under legitimate circumstances.

[0083] For example, during vehicle repair, it is usually necessary to access different ECUs using specialized diagnostic tools through an authorized dealer or service station. These tools can communicate with the ECUs using the correct secure access keys.

[0084] File integrity key: A file integrity key is a key used to maintain the integrity and reliability of data. It can ensure that files are not tampered with or damaged during transmission, so that the receiving end can receive a file that is completely consistent with the original file.

[0085] For example, before sending data to the recipient, the ECU can encrypt the data using a key, and the encrypted data is transmitted through the vehicle's communication network. The recipient can then decrypt the data using a corresponding key to obtain the original information.

[0086] Controller Area Network (CAN) Bus: The CAN bus is a serial communication protocol bus used for real-time applications. It is widely used in automotive electronic control systems and enables efficient communication between various ECUs.

[0087] Electrical / electronic (E / E) architecture: The automotive E / E architecture refers to the organizational structure and hardware / software systems of automotive electronic and electrical components that enable vehicle functionality. It emphasizes the interactions and interdependencies between components and between components and the vehicle environment, as well as the principles guiding design and evolution. For example, automotive E / E architectures can be categorized into distributed E / E architectures, domain-centralized E / E architectures, and centralized E / E architectures.

[0088] Distributed E / E Architecture: A distributed E / E architecture can be divided according to different vehicle functions, with each ECU designed based on specific functional requirements. Figure 2 shows a schematic diagram of a distributed E / E architecture based on a CAN bus. As shown in Figure 2, each ECU is responsible for implementing a single function and communicates with other ECUs through the CAN bus to realize the functions of the entire vehicle.

[0089] Domain-centralized E / E architecture: This architecture clusters the functions of multiple ECUs, allowing the vehicle to deploy only a few domain control units (DCUs) as the main control units. Figure 3 illustrates a schematic diagram of a domain-centralized E / E architecture based on Ethernet and CAN bus. As shown in Figure 3, this E / E architecture centrally manages all domain controllers through a central gateway (CGW), using Ethernet and CAN bus to handle different types of data transmission needs. Each DCU is responsible for data processing and functional decisions for its respective domain, and for controlling and managing the sensors and actuators within that domain.

[0090] Centralized E / E Architecture: A centralized E / E architecture can further integrate multiple DCUs into one or more multi-core heterogeneous system-on-chip (SoC) chips with stronger computing power and a central computing platform (CCP) combining multiple operating systems. Vehicle sensors and actuators are not deployed according to function, but rather connected to zone control units (ZCUs) based on their physical location. Figure 4 illustrates a schematic diagram of a centralized E / E architecture. As shown in Figure 4, four ZCUs are distributed in different parts of the vehicle. Each ZCU is responsible for managing sensors and actuators within a certain range, and each ZCU is connected to the CCP via Ethernet. Sensors can send collected data to the corresponding ZCU, which can then send the processed data to the CCP for processing and analysis. The CCP can issue commands based on the processing results, and these commands are then sent to the actuators through the ZCUs.

[0091] Master Node: The master node can be a high-level control unit in different E / E architectures responsible for coordinating, controlling, and managing other nodes or components. Master nodes typically possess strong computing, storage, and communication capabilities, enabling them to independently complete complex tasks. In this embodiment, the master node can receive detection tasks and test files from a cloud server.

[0092] Non-master node: A non-master node can be a control unit that relies on the master node to complete tasks. A non-master node can perform specific functions, such as sensors collecting data or actuators performing certain controls. In this embodiment, the non-master node cannot directly obtain the detection tasks and test files from the cloud server; it needs to obtain them from the master node or a proxy node.

[0093] Proxy Node: A proxy node is responsible for communication between upper-level and lower-level nodes. It collects data from each lower-level node and uploads the aggregated data to the upper-level node. It also distributes instructions from the upper-level node to the appropriate lower-level nodes.

[0094] For example, in a distributed E / E architecture, each ECU independently controls a function, so each ECU can be considered a master node.

[0095] For example, in a domain-centralized E / E architecture, each DCU can be responsible for controlling the sensors and actuators within a vehicle functional domain, thus each DCU can be considered a master node. Non-master nodes can be ECUs within the domain, such as door controllers.

[0096] For example, in a centralized E / E architecture, the CCP can process and analyze data from the entire vehicle and make the highest-level control decisions; therefore, the CCP can be considered the master control node. The ZCU can act as a secondary master control node, responsible for managing sensors and actuators in specific areas. Other ECUs can be considered non-master control nodes.

[0097] It should be understood that the master node and non-master node in this application are not limited to any single E / E structure. Therefore, the definition and applicability of master nodes and non-master nodes are not limited to distributed E / E architecture, domain-centralized E / E architecture, or centralized E / E architecture.

[0098] Driver files: Also known as "driver programs," driver files are configuration files written by hardware manufacturers based on the operating system. They translate the operating system's instructions into instructions that the hardware can understand, allowing the hardware to perform its functions. Driver files enable effective communication between the operating system and the hardware.

[0099] For example, in the case of an ECM upgrade, the driver files can ensure that the operating system and the engine can communicate normally.

[0100] Application (APP) files: APP files are application files designed for a specific operating system to implement the functions required by the user. APP files can include: executable code (the core logic of the application), resource files (such as images, audio, and video), metadata (such as version number and developer information), etc.

[0101] For example, vehicle navigation software can provide functions such as real-time navigation, route planning, and traffic information. The navigation software's APP file may include: map data files, navigation logic code, user interface resources, etc.

[0102] Calibration files: Calibration files are used to configure and optimize the performance of hardware devices. They can contain operating parameters for the hardware device under different conditions. Using calibration files, hardware devices can be made to operate stably under various conditions.

[0103] For example, when upgrading the ECM, the calibration file can include parameters and data for optimizing engine performance and behavior. These parameters can include those related to fuel control, ignition control, emissions control, temperature management, torque management, and more. The engine needs to refer to these parameters when performing specific functions.

[0104] ROM: A type of computer memory used to store data that is not frequently changed or permanent data, such as firmware or boot programs. ROM is non-volatile, meaning that data is not lost after power failure or system reset. Therefore, software version information can be stored in ROM, allowing the version information to remain unchanged during use.

[0105] Random access memory (RAM): A type of computer memory that allows for fast data reading and writing. It is characterized by high access speed, but data is lost after power failure or system reset. Therefore, it can be used to store temporary data; for example, driver files loaded into RAM do not affect driver files stored in ROM.

[0106] In the field of intelligent vehicles, after a vehicle leaves the factory, its software needs continuous iteration and updates to constantly optimize the overall functionality of the vehicle. Vehicle manufacturers can use OTA (Over-The-Air) functionality to add new software features, fix software defects, and optimize software functions, thereby keeping the vehicle's software up-to-date. This helps maintain and improve vehicle performance and also enhances user safety.

[0107] With the increasing frequency of OTA (Over-The-Air) updates, it has become an indispensable feature in vehicles. Therefore, ensuring the completeness of OTA functionality throughout the vehicle's lifecycle and beyond is crucial for guaranteeing overall vehicle performance and user experience. In other words, the proper functioning of OTA is a key factor in assessing vehicle quality.

[0108] In some implementations, the completeness of OTA functionality can be verified by executing a full OTA upgrade process. That is, a real upgrade task is used to comprehensively verify that each step of the OTA function can complete its work as expected.

[0109] Figure 5 shows a schematic flowchart of a complete OTA upgrade method 500. As shown in Figure 5, method 500 includes:

[0110] S501: OTA task issuance.

[0111] Vehicle manufacturers send OTA upgrade tasks to vehicles via servers. For example, the OTA upgrade task may include: upgrade version information, upgrade content, upgrade importance level, upgrade package download information, upgrade conditions, upgrade restrictions, upgrade time, and other information.

[0112] S502: Software package download.

[0113] After receiving an OTA upgrade request from the vehicle manufacturer, the vehicle can connect to the manufacturer's server via the vehicle communication module to download the corresponding software package.

[0114] For example, the downloaded software package can be 2000MB in size, including driver files, application files, calibration files, etc.

[0115] Because the software package is large, it will take a long time to download.

[0116] For example, at a download speed of 8 Mbps, a 2000 MB package would take approximately 30 minutes to download.

[0117] For example, in a congested network environment, such as at a download speed of 1 Mbps, a 2000 MB package would take approximately 4.5 hours to download.

[0118] S503: Upgrade condition check.

[0119] The purpose of upgrade condition checks is to avoid potential risks during the upgrade process. These checks may include, but are not limited to, the following:

[0120] (1) Vehicle battery charge check. This check helps determine whether the battery charge can support the entire OTA upgrade process. For example, if the vehicle battery charge is only 5%, the vehicle cannot use the OTA function for upgrade.

[0121] (2) Vehicle driving status check. This check helps determine if the vehicle is in a safe upgrade mode. For example, some software related to core vehicle functions needs to be upgraded while the vehicle is parked, such as powertrain software, autonomous driving system software, and chassis control system software. If these software updates are performed while the vehicle is in motion, it may lead to loss of vehicle control, functional failure, or safety risks.

[0122] (3) Communication status check. This check helps to confirm whether the network connection between the vehicle and the server is stable and reliable, and whether the signal strength is sufficient to support data transmission.

[0123] S504: Enter OTA upgrade mode.

[0124] After entering OTA upgrade mode, the vehicle can pause some non-critical functions, and the central control screen can display relevant content to prompt the user not to operate, thereby avoiding interference with the OTA upgrade and causing it to be interrupted.

[0125] S505: Installation process.

[0126] The installation process refers to the process during OTA upgrades where the vehicle installs the downloaded installation package into the ECU.

[0127] In some implementations, the vehicle can verify the completeness of the downloaded software package and its compatibility with the ECU. If the installation package is corrupted or tampered with, the installation process is terminated; if the installation package is incompatible with the ECU, the installation process is terminated.

[0128] In some implementations, the vehicle can back up its current software so that it can be restored to its original state if problems occur during the upgrade process.

[0129] During the installation process, existing software can be overwritten, and new software can be written into the ECU's flash memory.

[0130] After installation, the vehicle can verify that the new software has been installed correctly.

[0131] S506: Exit OTA upgrade mode.

[0132] After exiting OTA upgrade mode, the vehicle can restore some non-critical functions that were previously suspended, and the central control screen can display relevant content to prompt the user that the upgrade is complete.

[0133] In method 500, downloading and installing software packages typically takes a long time.

[0134] For example, Figure 6 provides a schematic flowchart of a software installation method 600. As shown in Figure 6, method 600 includes:

[0135] S601: Pre-programmed.

[0136] Pre-programming can be a series of checks or initialization operations performed on the ECU before the software installation process begins. The purpose of pre-programming is to ensure the ECU is in a normal working state so that new software can be installed.

[0137] For example, the vehicle can perform ECU initialization operations, which may include lowering the vehicle speed below a set safety threshold, such as 10 km / h. The ECU can prevent software updates until the vehicle speed falls below the safety threshold, thus avoiding safety issues during software updates.

[0138] S602: Driver file transfer.

[0139] Driver file transfer can be the process of transferring new driver files to the ECU and installing them.

[0140] S603: APP file transfer.

[0141] APP file transfer can be the process of transferring a new APP file to the ECU and installing it.

[0142] S604: Calibrate file transfer.

[0143] Calibration file transfer can be the process of transferring new calibration files to the ECU and installing them.

[0144] S605: Post-programming.

[0145] Post-programming can be understood as the "exit installation" stage in the software installation process.

[0146] For example, post-programming may include: a control prompting device informing the user that the software installation is complete and the vehicle can be resumed.

[0147] As can be seen from the above, in method 600, when the size of the transferred file is large, the installation time of the software package is relatively long. For example, the installation time of the software package can range from 30 minutes to 120 minutes.

[0148] Therefore, performing a complete OTA upgrade can be time-consuming. For example, the time required to perform a complete OTA upgrade can range from 30 minutes to 180 minutes. This results in excessively low efficiency in verifying the completeness of OTA functions, failing to meet the needs of rapid iterative development.

[0149] For example, to improve production efficiency, vehicle manufacturers do not perform a complete OTA upgrade process to verify the completeness of OTA functions before each vehicle rolls off the production line, thus saving time and costs. Similarly, to enhance user experience, 4S dealerships do not verify the completeness of OTA functions during vehicle repairs, thus reducing customer waiting time. Furthermore, users themselves do not verify the completeness of OTA functions every time they use their vehicle, thus saving travel time.

[0150] Furthermore, vehicle manufacturers are responsible for developing the software and sending OTA (Over-The-Air) update requests to the vehicles; that is, the OTA function is remotely controlled by the vehicle manufacturer. Therefore, a vehicle can only use the OTA function for upgrades when the vehicle manufacturer initiates the OTA update request. This means that, apart from situations where the vehicle manufacturer actively pushes an update request, the vehicle will not perform OTA updates, and users cannot determine whether the vehicle's OTA function is working properly.

[0151] For example, if the OTA function malfunctions, users will not be aware of this situation in time. They will only discover that the OTA function is unusable when the vehicle needs an OTA upgrade later, which will lead to software upgrade failure. This will seriously affect the user experience and even increase the safety risks of driving.

[0152] As can be seen from the above, how to quickly and efficiently verify the completeness of vehicle OTA functions and provide a more flexible verification method is an urgent problem to be solved.

[0153] The following describes the inspection method, vehicle, and apparatus provided in the embodiments of this application. The inspection method provided in the embodiments of this application can shorten the time spent on software package download and installation during OTA upgrades, and realize rapid inspection of OTA functional completeness.

[0154] Figure 7 shows a schematic flowchart of an inspection method 700 provided in an embodiment of this application. As shown in Figure 7, method 700 includes:

[0155] S701: Receives a first inspection task and a first test file. The first inspection task is used to instruct the OTA function to be inspected, and the first test file contains only driver files.

[0156] The driver file can be a driver file for all ECUs in the vehicle.

[0157] Optionally, receiving the first inspection task and the first test file includes receiving the first inspection task and the first test file from a cloud server.

[0158] As can be seen from the above, vehicle manufacturers can send tasks related to OTA (Over-The-Air) functionality to vehicles via cloud servers. These tasks can include upgrade tasks and verification tasks.

[0159] Specifically, when a vehicle needs a software upgrade, the cloud server can send an upgrade task to the vehicle. This task type indicates that the task is a standard OTA upgrade. When it is necessary to verify the OTA function, the cloud server can send a verification task to the vehicle. This task type indicates that the task is not a "real OTA upgrade".

[0160] It should be noted that the above classification of task types is for illustrative purposes only, and the classification criteria for tasks in this application embodiment are not limited.

[0161] The first test file contains only driver files, meaning it does not contain other application files or calibration files. Therefore, the size of the first test file can be significantly smaller than that of a normal software package. For example, a normal software package is 2000MB in size, while the test software package is 1MB. At a download speed of 8Mbps, a 1MB package will take approximately 1 second to download. At a download speed of 1Mbps, a 1MB package will take approximately 8 seconds to download.

[0162] S702: Based on the first inspection task, perform an inspection on the first node to obtain the first inspection result, which is used to indicate the usage status of the first node.

[0163] The first node can be the master control node in the ECU. The description of the master control node has been provided previously and will not be repeated here. In this embodiment, the master control node can proactively perform hardware and software checks during the pre-programming stage.

[0164] S703: Send the first test result.

[0165] Figure 8 shows a schematic flowchart of a verification method 800 for a master control node provided in an embodiment of this application. As shown in Figure 8, method 800 includes:

[0166] S801: Receives the OTA verification task and the first test file sent by the cloud server.

[0167] The master node can determine whether a task issued by the cloud server is a "test task" or a "real upgrade" based on the task's identifier.

[0168] S802: Perform software package verification.

[0169] For example, software package verification may include integrity verification, encryption verification, certificate / key verification, etc.

[0170] Integrity verification may include checking whether the test software package is complete, thereby determining that there is no damaged or missing data.

[0171] Encryption verification may include: verifying the validity of the encryption of the test software package and ensuring that the software package is authorized.

[0172] Certificate / key verification may include verifying whether the certificate and digital signature of the test software package originate from a legitimate source.

[0173] S803: The master node performs software and hardware verification.

[0174] For example, hardware verification of the master node may include:

[0175] (1) Check whether the sensors and actuators connected to the ECU can respond normally. For example, check whether the communication module is working properly.

[0176] (2) Check whether the internal components of the ECU (memory, processor, etc.) are working properly. For example, check whether the storage space is sufficient; another example is to check whether there are bad blocks in the flash memory.

[0177] Hardware testing helps avoid problems caused by hardware failures during software installation.

[0178] For example, software verification of the master node may include:

[0179] (1) Check whether the current software version and system status are normal.

[0180] (2) Check if there are any running tasks.

[0181] (3) Check if the key in the ECU is normal.

[0182] (4) Check if the certificate in the ECU is normal.

[0183] S804: Determine if there is a problem with the master node.

[0184] If no problem is found, proceed to S805. Otherwise, proceed to S806.

[0185] S805: The verification was successful and reported to the cloud server.

[0186] S806: Report the problem to the cloud server.

[0187] For example, if problems such as corrupted software packages, invalid certificates, or insufficient storage space are found during the inspection process, it means that the vehicle is currently unable to perform OTA functions normally. Therefore, the master control node can report these problems to the cloud server.

[0188] In this embodiment of the application, the problem reported by the master node to the cloud server may include not only its own test results (first test results), but also the test results of the subordinate nodes (second test results).

[0189] Optionally, method 700 further includes: if the first node has one or more subordinate nodes, sending a first inspection task and a first test file to one or more subordinate nodes; receiving a second inspection result sent by one or more subordinate nodes, the second inspection result being used to indicate the usage status of one or more subordinate nodes; and sending the second inspection result.

[0190] In some implementations, the slave nodes of the master node can be non-master nodes.

[0191] Optionally, one or more slave nodes include a first slave node, which is a non-master node, and receive a second verification result sent by one or more slave nodes, including: receiving the second verification result sent by the first slave node when the first test file is installed on the first slave node.

[0192] The first slave node is a non-master node in the ECU. The description of non-master nodes has been provided previously and will not be repeated here. In this embodiment, the non-master node can actively perform hardware diagnostics and checks during the pre-programming stage. However, due to capability limitations, it cannot determine the type of the currently received task, and therefore cannot perform software checks. Therefore, the non-master node can perform software checks based on its performance after installing the first test file.

[0193] The following section uses the verification of file integrity keys as an example to introduce the verification methods for non-master nodes in terms of software.

[0194] Optionally, before receiving the second verification result sent by the first slave node, method 700 further includes: determining a first value based on the first test file and the first file integrity key, the first value being used to verify the second file integrity key in the first slave node; sending the first value to the first slave node; wherein receiving the second verification result sent by the first slave node includes: receiving the verification result for the second file integrity key sent by the first slave node.

[0195] Optionally, method 700 further includes: sending a flash diagnostic command to the first slave node, the flash diagnostic command being used to instruct the first slave node to install the first test file.

[0196] Optionally, sending the first verification task and the first test file to one or more slave nodes includes: sending the first test file to the RAM of the first slave node.

[0197] The above method can be implemented collaboratively by the master node and non-master nodes. As an example, a specific step-by-step example is given below:

[0198] Step a1: The master node sends a flash diagnostic command to the non-master node, instructing the non-master node to install the driver file to complete the OTA function verification. The non-master node receives the flash diagnostic command.

[0199] Step b1: The master node transfers the driver file to the RAM of the non-master node, and the non-master node installs the driver file.

[0200] Transferring the driver files to the RAM of a non-master node allows for rapid OTA (Over-The-Air) functionality testing. After testing, the driver files in RAM are automatically cleared by power-off or reset, while the driver files in ROM remain unaffected.

[0201] Step c1: The master node uses the first test file and the correct file integrity key (a preset legitimate key) to generate a first value for verification using a specific algorithm. This first value is then sent to the non-master nodes for subsequent comparison. The specific algorithm could be, for example, a message authentication code (MAC) algorithm or a hash algorithm.

[0202] Step d1: The non-master node calculates a second value for verification based on the first test file and the non-master node's current file integrity key.

[0203] Step e1: The non-master node compares the received first value with the locally calculated second value. If the first and second values ​​match, the file integrity key of the non-master node is correct; if the first and second values ​​do not match, the key of the non-master node is faulty.

[0204] Step f1: Non-master nodes can send the test results back to the master node, and the master node can send the test results back to the cloud server after receiving them.

[0205] In the above method steps, the order of steps c1 and d1 is not restricted.

[0206] Optionally, the first slave node may use embedded storage.

[0207] It should be noted that in embedded systems, due to the characteristics of storage media (such as flash), the flashing of driver files must be complete; otherwise, the embedded system will become unusable.

[0208] Figure 9 shows a schematic flowchart of a verification method 900 for a non-master node provided in an embodiment of this application. As shown in Figure 9, method 900 includes:

[0209] S901: Non-master node receives the verification task and the first test file.

[0210] As can be seen from the above, non-master nodes cannot directly obtain the inspection task and the first test file from the cloud server. Therefore, the master node needs to send the inspection task and the first test file to the non-master nodes.

[0211] For example, the master node can directly send the verification task and the first test file to the non-master node.

[0212] For example, the master node can send the verification task and the first test file to the non-master node through the proxy node.

[0213] In the scenario shown in Figure 10, the proxy node can simply forward information without controlling the business logic.

[0214] Figure 10 illustrates an architecture including proxy nodes according to an embodiment of this application. As shown in Figure 10, node A is the master node, node B is the proxy node, and nodes C and D are non-master nodes. Nodes B, C, and D have independently running software modules; that is, node B corresponds to software module 1, node C corresponds to software module 2, and node D corresponds to software module 3. In this scenario, nodes B, C, and D possess independent communication protocols or service interfaces, thus node A can communicate with nodes B, C, and D respectively.

[0215] In Figure 10, node A can send a verification task t and a test file m to node B. The verification task t can include verification task t1 for node B, verification task t2 for node C, and verification task t3 for node D; the test file m can include test file m1 for node B, test file m2 for node C, and test file m3 for node D. After receiving the verification task t and test file m, node B can act as a "forwarding intermediary," forwarding verification task t2 and test file m2 to node C, and forwarding verification task t3 and test file m3 to node D.

[0216] In the scenario shown in Figure 11, the proxy node can control the business logic. That is, after receiving the inspection task and test file, the proxy node can decide independently what to forward to the subordinate node, and is not just a "forwarding intermediary".

[0217] Figure 11 illustrates another architecture diagram including proxy nodes provided in an embodiment of this application. As shown in Figure 11, node E is the master node, node F is the proxy node, and nodes G and H are non-master nodes. Nodes F, G, and H collectively correspond to a software module 4. In this scenario, node E can communicate with node F, but cannot communicate with nodes G and H.

[0218] In Figure 11, node E can send inspection task t' and test file m' to node F. After receiving the inspection task and test file, node F can flexibly send the inspection task and test file to node G and node H according to the preset business logic.

[0219] S902: Conditional test.

[0220] S903: Determine if there is an anomaly in the conditional test.

[0221] If an exception is found, execute S909. Otherwise, execute S904.

[0222] Among them, the condition check can be a series of checks performed on the non-master node in the pre-programmed process, such as checking the hardware status of the non-master node.

[0223] For example, in the scenario shown in Figure 10, if bad blocks are found in the flash memory of a non-master node C during the condition check, the problem can be reported to the master node A. The problem information can be forwarded to the master node A via proxy node B.

[0224] For example, in the scenario shown in Figure 11, if an anomaly is found in the communication module of the non-master node G during the condition check, the problem can be reported to the agent node F.

[0225] S904: Verification of the secure access key.

[0226] S905: Determine if the security access key is abnormal.

[0227] If an exception is found, execute S909. Otherwise, execute S906.

[0228] As mentioned earlier, secure access keys are used for authentication and authorization to ensure that only authorized requests can access or modify the ECU. Therefore, an incorrect secure access key can lead to problems such as failed normal communication and denied secure access. Determining whether the secure access key is abnormal helps to identify functional faults promptly, allowing for timely repair of the secure access key and ensuring the integrity of OTA functionality.

[0229] As an example, the following is a specific example of the steps to verify the security access key of a non-master node:

[0230] Step a2: The master node sends a first request to the non-master node to request the first data.

[0231] Step b2: The non-master node receives the first request from the master node, calculates the first data based on the first request and related algorithms, and sends the first data to the master node.

[0232] Step c2: The master node receives the first data and, based on the first data and the correct security access key, calculates the third value. The master node then sends the calculated third value to the non-master nodes.

[0233] Step d2: The non-master node calculates the fourth value based on the first data and the current security access key of the non-master node.

[0234] Step e2: The non-master node compares the third and fourth values. If the third and fourth values ​​match, the file integrity key of the non-master node is correct; if the third and fourth values ​​do not match, the key of the non-master node is faulty.

[0235] Step f2: Non-master nodes can send the test results back to the master node, and the master node can send the test results back to the cloud server after receiving them.

[0236] In the above method steps, the order of steps c2 and d2 is not restricted.

[0237] S906: Driver files are installed on non-master nodes.

[0238] S907: Verification of the file integrity key.

[0239] S908: Determine if the file integrity key is abnormal.

[0240] If an exception is found, execute S909. Otherwise, execute S910.

[0241] As mentioned earlier, the file integrity key is used to verify the integrity and authenticity of the transmitted file, ensuring that the transmitted driver file has not been tampered with or corrupted. Therefore, verifying the file integrity key can prevent software update failures or the introduction of security risks.

[0242] The verification of the file integrity key can be referred to in the previous steps a1-f1, and will not be repeated here.

[0243] S910: Determine whether it is necessary to check the subordinate node.

[0244] If necessary, the slave node can execute steps S901 to S910. Otherwise, execute S911.

[0245] For example, a slave node of a non-master node can be a non-master node, and the non-master node can continue to be tested according to method 900.

[0246] S911: Feedback of normal test results.

[0247] In other implementations, the slave nodes of the master node can be the master node.

[0248] For example, one or more slave nodes include a second slave node, which is the master node. The verification of the second slave node can refer to the steps in method 800, that is, the second slave node can receive the first verification task and the first test file sent by the first node, actively complete the verification of its own software and hardware, and feed back the verification results to the first node.

[0249] Optionally, method 700 further includes: saving the first test file in the vehicle.

[0250] By storing the first test file sent from the cloud in the vehicle, when the vehicle needs to perform OTA function verification again, it can be performed directly without retrieving it from the cloud server.

[0251] Figure 12 shows a schematic flowchart of an OTA function verification method 1200 provided in an embodiment of this application. As shown in Figure 12, method 1200 includes:

[0252] S1201: OTA verification task issued.

[0253] In some implementations, the task type can be obtained as "inspection task" through the task type field.

[0254] S1202: The test software package is configured by the cloud server, and the vehicle downloads the test software package.

[0255] S1203: Upgrade condition check.

[0256] S1204: Enter OTA upgrade mode.

[0257] The "upgrade condition check" and "enter OTA upgrade mode" mentioned above have already been introduced in the descriptions of S503 and S504, and will not be repeated here.

[0258] S1205: Perform a simplified installation process.

[0259] In this embodiment, the master node can proactively perform software and hardware checks based on the received task type, without performing the installation process. Non-master nodes can perform hardware checks and execute a simplified installation process to check the software. The simplified installation process includes pre-programming, driver file transfer, and post-programming. Compared to the installation process in method 600, the simplified installation process reduces the steps of APP file transfer and calibration file transfer.

[0260] S1206: Exit OTA upgrade mode.

[0261] S1207: Test package archive.

[0262] For example, the test package can be stored locally on the vehicle. When an OTA test is required next time, the test package can be retrieved directly from the vehicle, thus saving download time.

[0263] In some implementations, the time required to perform an OTA function once in this application embodiment can be within 10 minutes.

[0264] Optionally, method 700 further includes: receiving a first upgrade file when a first test result indicates that the first node is in a normal state of use, and a second test result indicates that one or more subordinate nodes are in a normal state of use, the first upgrade file being used for upgrading the first node and at least some of the one or more subordinate nodes.

[0265] Figure 13 illustrates a schematic diagram of a vehicle factory inspection scenario provided in an embodiment of this application. As shown in Figure 13, production line workers can use factory inspection equipment at the inspection station to notify the cloud server to issue an OTA (Over-The-Air) function inspection task. In response to the inspection request, the cloud server sends the OTA function inspection task and test software package to the vehicles coming off the production line. The vehicles off the production line perform the inspection according to the issued inspection task and test software package, and return the inspection results to the cloud server, which in turn returns them to the factory inspection equipment. Furthermore, after the inspection is completed, the vehicle can cache the test software package for repeated use in later vehicle maintenance and daily use.

[0266] The factory inspection equipment can be either hardware or software, and this application does not limit the type of factory inspection equipment.

[0267] The test software package can be temporarily built on a cloud server or pre-installed on a cloud server. This application embodiment does not limit the source and method of building the test software package.

[0268] Figure 14 illustrates a schematic diagram of a 4S store repair scenario provided in an embodiment of this application. As shown in Figure 10, 4S store staff initiate OTA function testing through after-sales inspection equipment. After the after-sales inspection vehicle completes the inspection, the results are displayed to the staff, who can then proceed with further processing based on the inspection results.

[0269] Figure 15 illustrates a user self-test scenario provided in an embodiment of this application. As shown in Figure 15, the vehicle owner can click the OTA function test control displayed on the vehicle's display device. Since the vehicle has a test software package cached internally, the vehicle can be directly triggered to perform a test. After the test is completed, the test results can be displayed on the vehicle's display device.

[0270] It should be noted that this embodiment is also applicable to after-sales inspection scenarios, meaning that 4S store staff can also use this inspection control to check the completeness of the vehicle's OTA function.

[0271] Figures 16-20 illustrate a set of user-guided GUIs provided in embodiments of this application.

[0272] As shown in Figure 16, the content displayed on the display screen 1601 (i.e., the central control screen) is as indicated by the arrows, including a content display area 1602 and a function bar 1603. For example, the content display area 1602 may include: icons for various applications, each icon used to activate one application; a login control 1604 (in the unlogged-in state) for logging into the vehicle system; and Bluetooth, Wi-Fi, and cellular signal icons, respectively indicating the vehicle's Bluetooth on and / or connection status, Wi-Fi on status, and cellular signal strength. The function bar 1603 includes a homepage icon and volume controls, used to control the display of the homepage in the content display area 1602 and adjust the volume of the sound device, respectively.

[0273] In some implementations, when the vehicle inspection icon 1605 is detected to be pressed and held, the display screen 1601 can be controlled to display the interface shown in Figure 17. As shown in Figure 17, this interface is the vehicle inspection interface, including air conditioning function inspection control, music playback function inspection control, and OTA function inspection control 1701.

[0274] In some implementations, when the OTA function verification control 1701 is clicked, the display screen 1601 can be controlled to display the interface shown in Figure 18. As shown in Figure 18, this interface is for OTA function verification, including a left menu bar 1801 and a right status display area 1802. The left menu bar 1801 includes: historical verification data control, last verification data control, and automatic verification settings control. The right status display area 1802 includes a car icon and a status icon. For example, when the vehicle is undergoing OTA function verification, the status icon will display a loading animation effect with the text "Verifying". The meaning of the same icon will not be repeated below.

[0275] In some implementations, if the OTA function test result is abnormal, the display screen 1601 can be controlled to display a prompt bar 1901 as shown in Figure 19. This prompt bar 1901 includes the prompt title "OTA Function Test Abnormal," the specific prompt content "Dear user, during the OTA function test of your device, we detected the following abnormality: communication module communication abnormality. This abnormality may cause OTA upgrade failure; we recommend contacting after-sales support," a "View Details" control, and a "Contact After-Sales" control. Users can click the "View Details" control to learn more about the specific circumstances of the OTA function test abnormality, and click the "Contact After-Sales" control to obtain various contact methods to promptly contact the manufacturer's after-sales service team.

[0276] In some implementations, if the OTA function test result is normal, the display screen 1601 can be controlled to display a prompt bar 2001 as shown in Figure 20. The prompt bar 2001 includes the prompt title "OTA function test normal", the specific prompt content "Dear user, your device's OTA function is normal. Thank you for choosing our product! We will continue to provide you with a better experience" and a confirmation control.

[0277] Figure 21 illustrates another user self-test scenario provided by an embodiment of this application. As shown in Figure 21, the user can trigger the vehicle to perform an OTA function test via a mobile device. After the test is completed, the user can view the test results on a mobile app.

[0278] Figures 22-26 illustrate a set of user-friendly GUIs provided in embodiments of this application.

[0279] As shown in Figure 22, this interface is a remote vehicle management interface for mobile phones, which can be used to manage and control vehicle functions. The interface includes a top area, a main function area, an information display area, and other function areas. For example, the top area includes a cellular network signal icon, a Wi-Fi function icon, and a time indicator; the main function area includes start controls, lock controls, unlock controls, and trunk opening controls; the information display area includes temperature information and remaining vehicle battery power; and other function areas include a child mode control, connected device controls, vehicle location controls, a timer function control, and a function verification control 2201.

[0280] In some implementations, when the function verification control 2201 is clicked, the mobile phone screen can be controlled to display the interface shown in Figure 23. As shown in Figure 23, this interface is a function verification interface, including the OTA function control 2301 and the audio function control.

[0281] In some implementations, when the OTA function control 2301 is clicked, the phone screen can be controlled to display the interface shown in Figure 24. As shown in Figure 24, this interface is the OTA function verification interface. A loading animation consisting of multiple black dots is displayed in the center of the interface, indicating that the vehicle is undergoing OTA function verification. The words "Verification in progress" are displayed below the loading animation. Through this interface, users can intuitively understand the current verification status.

[0282] In some implementations, if the OTA function test results are abnormal, the phone screen can be controlled to display the interface shown in Figure 25. As shown in Figure 25, this interface includes a warning icon, the message "Function Abnormality", the specific message "Dear user, we detected the following abnormality during the OTA upgrade function test for your device: Communication module communication abnormality. This abnormality may cause the OTA upgrade to fail. We recommend contacting after-sales support for assistance," a view details control, and a contact after-sales support control.

[0283] In some implementations, if the OTA function test result is normal, the phone screen can be controlled to display the interface shown in Figure 26. As shown in Figure 26, the correct icon appears in the center of the phone screen, accompanied by the words "Function Normal".

[0284] Figure 27 shows a schematic block diagram of an inspection device 2700 provided in an embodiment of this application. The device includes: a receiving unit, configured to: receive a first inspection task and a first test file, wherein the first inspection task is used to instruct the inspection of OTA function and the first test file contains only driver files; an execution unit, configured to: perform an inspection of a first node based on the first inspection task to obtain a first inspection result, wherein the first inspection result is used to indicate the usage status of the first node; and a sending unit, configured to: send the first inspection result.

[0285] Figure 27 shows a schematic block diagram of an inspection device 2700 provided in an embodiment of this application. The device includes: a receiving unit 2710, configured to: receive a first inspection task and a first test file, wherein the first inspection task is used to instruct the inspection of OTA function and the first test file contains only driver files; an execution unit 2720, configured to: perform an inspection of a first node based on the first inspection task to obtain a first inspection result, wherein the first inspection result is used to indicate the usage status of the first node; and a sending unit 2730, configured to: send the first inspection result.

[0286] Optionally, the sending unit 2730 is further configured to: send a first inspection task and a first test file to one or more subordinate nodes when the first node has one or more subordinate nodes; the receiving unit 2710 is further configured to: receive a second inspection result sent by one or more subordinate nodes, the second inspection result being used to indicate the usage status of one or more subordinate nodes; the sending unit 2730 is further configured to: send the second inspection result.

[0287] Optionally, one or more slave nodes include a first slave node, which is a non-master node. The receiving unit 2710 is further configured to: receive a second verification result sent by the first slave node when the first slave node completes the installation of the first test file.

[0288] Optionally, the sending unit 2730 is further configured to: send a flash diagnostic command to the first slave node, the flash diagnostic command being used to instruct the first slave node to install the first test file.

[0289] Optionally, the sending unit 2730 is also configured to: send a first test file to the random access memory (RAM) of the first slave node.

[0290] Optionally, the first slave node may use embedded storage.

[0291] Optionally, the device further includes a determining unit 2740, configured to: determine a first value based on a first test file and a first file integrity key, the first value being used to verify a second file integrity key in a first slave node; a sending unit 2730, further configured to: send the first value to the first slave node; and a receiving unit 2710, further configured to: receive the verification result for the second file integrity key sent by the first slave node.

[0292] Optionally, the receiving unit 2710 is further configured to: receive a first upgrade file when the first verification result indicates that the first node is in a normal state and the second verification result indicates that one or more subordinate nodes are in a normal state, the first upgrade file being used for upgrading the first node and at least some of the one or more subordinate nodes.

[0293] Optionally, the receiving unit 2710 is also used to: receive the first inspection task and the first test file from the cloud server.

[0294] It should be understood that the division of units in the above device is only a logical functional division. In actual implementation, they can be fully or partially integrated into a single physical entity, or they can be physically separated. Furthermore, the units in the device can be implemented by a processor calling software; for example, the device includes a processor connected to memory, which stores instructions. The processor calls the instructions stored in memory to implement any of the above methods or to implement the functions of each unit in the device. The processor can be, for example, a general-purpose processor, such as a CPU or microprocessor, and the memory can be internal or external to the device. Alternatively, the units in the device can be implemented as hardware circuits. The functions of some or all units can be implemented through the design of the hardware circuits, which can be understood as one or more processors. For example, in one implementation, the hardware circuit is an ASIC, and the functions of some or all units are implemented through the design of the logical relationships between the components within the circuit. In another implementation, the hardware circuit can be implemented using a PLD, such as an FPGA, which can include a large number of logic gates. The connection relationships between the logic gates are configured through configuration files, thereby implementing the functions of some or all units. All units of the above device can be implemented entirely through processor calling software, or entirely through hardware circuits, or partially through processor calling software and the remaining parts through hardware circuits.

[0295] In this application embodiment, a processor is a circuit with signal processing capabilities. In one implementation, the processor can be a circuit with instruction reading and execution capabilities, such as a CPU, microprocessor, GPU, or DSP. In another implementation, the processor can implement certain functions through the logical relationships of hardware circuits. These logical relationships are fixed or reconfigurable. For example, the processor may be a hardware circuit implemented as an ASIC or PLD, such as an FPGA. In a reconfigurable hardware circuit, the process of the processor loading a configuration document and configuring the hardware circuit can be understood as the processor loading instructions to implement the functions of some or all of the above units. Furthermore, it can also be a hardware circuit designed for artificial intelligence, which can be understood as an ASIC, such as an NPU, TPU, or DPU.

[0296] As can be seen, each unit in the above device can be one or more processors (or processing circuits) configured to implement the above methods, such as: CPU, GPU, NPU, TPU, DPU, microprocessor, DSP, ASIC, FPGA, or a combination of at least two of these processor forms.

[0297] Furthermore, the units in the above devices can be integrated in whole or in part, or they can be implemented independently. In one implementation, these units are integrated together as a System-on-a-Chip (SoC). The SoC may include at least one processor for implementing any of the above methods or implementing the functions of the units in the device. The at least one processor may be of different types, such as CPU and FPGA, CPU and AI processor, CPU and GPU, etc.

[0298] This application also provides an inspection device, which includes: a memory for storing a computer program; and a processor for executing the computer program stored in the memory, so that the device performs the methods or steps described in the above embodiments.

[0299] This application also provides a vehicle that may include the aforementioned inspection device 2700.

[0300] This application also provides a computer-readable storage medium storing instructions thereon, which, when executed by a processor, cause the processor to implement the methods or steps described above.

[0301] This application also provides a computer program product, including computer program code, which, when run on a computer, causes the computer to perform the methods or steps described above.

[0302] This application also provides a chip, which includes a circuit for performing the methods or steps described in the above embodiments.

[0303] In implementation, each step of the above method can be completed by integrated logic circuits in the processor's hardware or by instructions in software. The method disclosed in the embodiments of this application can be directly implemented by a hardware processor, or by a combination of hardware and software modules within the processor. The software modules can reside in random access memory, flash memory, read-only memory, programmable read-only memory, power-on erasable programmable memory, registers, or other mature storage media in the art. This storage medium is located in memory, and the processor reads information from the memory and, in conjunction with its hardware, completes the steps of the above method. To avoid repetition, detailed descriptions are omitted here.

[0304] It should be understood that in the embodiments of this application, the memory may include read-only memory and random access memory, and provides instructions and data to the processor.

[0305] It should also be understood that, in the various embodiments of this application, the order of the above-mentioned processes does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0306] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0307] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0308] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

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

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

[0311] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

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

Claims

1. A method of inspection, characterized by, The method includes: Receive a first inspection task and a first test file, wherein the first inspection task is used to instruct the inspection of the OTA function, and the first test file contains only driver files; Based on the first inspection task, an inspection of the first node is performed to obtain a first inspection result, which is used to indicate the usage status of the first node. Send the first test result.

2. The method of claim 1, wherein, The method further includes: If the first node has one or more subordinate nodes, the first inspection task and the first test file are sent to the one or more subordinate nodes; Receive a second verification result sent by one or more subordinate nodes, the second verification result being used to indicate the usage status of one or more subordinate nodes; Send the second test result.

3. The method of claim 2, wherein, The one or more subordinate nodes include a first subordinate node, which is a non-master node. Receiving the second verification result sent by the one or more subordinate nodes includes: If the first slave node completes the installation of the first test file, the second verification result sent by the first slave node is received.

4. The method of claim 3, wherein, The method further includes: Send a flash diagnostic command to the first slave node, the flash diagnostic command being used to instruct the first slave node to install the first test file.

5. The method according to claim 3 or 4, characterized in that, Sending the first verification task and the first test file to the one or more subordinate nodes includes: Send the first test file to the random access memory (RAM) of the first slave node.

6. The method according to any one of claims 3-5, characterized in that, The first slave node uses embedded storage.

7. The method according to any one of claims 3-6, characterized in that, Before receiving the second verification result sent by the first subordinate node, the method further includes: Based on the first test file and the first file integrity key, a first value is determined, which is used to verify the second file integrity key in the first subordinate node; Send the first value to the first subordinate node; The step of receiving the second verification result sent by the first subordinate node includes: Receive the verification result of the second file integrity key sent by the first subordinate node.

8. The method according to any one of claims 2-7, characterized in that, The method further includes: If the first test result indicates that the first node is in a normal state of use, and the second test result indicates that the one or more subordinate nodes are in a normal state of use, a first upgrade file is received. The first upgrade file is used for upgrading the first node and at least some of the one or more subordinate nodes.

9. The method according to any one of claims 1-8, characterized in that, The receiving of the first inspection task and the first test file includes: Receive the first verification task and the first test file from the cloud server.

10. An inspection apparatus characterized by comprising: The device includes: The receiving unit is configured to: receive a first inspection task and a first test file, wherein the first inspection task is used to instruct the inspection of the OTA function, and the first test file contains only driver files; The execution unit is configured to: perform an inspection of the first node based on the first inspection task, and obtain a first inspection result, wherein the first inspection result is used to indicate the usage status of the first node; The sending unit is used to send the first test result.

11. The apparatus according to claim 10, characterized in that, The sending unit is further configured to: send the first verification task and the first test file to the one or more subordinate nodes when the first node has one or more subordinate nodes; The receiving unit is further configured to: receive a second verification result sent by the one or more subordinate nodes, wherein the second verification result is used to indicate the usage status of the one or more subordinate nodes; The sending unit is further configured to: send the second verification result.

12. The apparatus of claim 11, wherein, The one or more subordinate nodes include a first subordinate node, which is a non-master node. The receiving unit is further configured to: receive the second verification result sent by the first slave node when the first slave node completes the installation of the first test file.

13. The apparatus according to claim 12, characterized in that, The sending unit is further configured to: send a flash diagnostic command to the first slave node, the flash diagnostic command being used to instruct the first slave node to install the first test file.

14. The apparatus according to claim 12 or 13, characterized in that, The sending unit is further configured to: send the first test file to the random access memory (RAM) of the first slave node.

15. The apparatus of any one of claims 12-14, wherein, The first slave node uses embedded storage.

16. The apparatus of any one of claims 12-15, wherein, The device further includes a determining unit, configured to: determine a first value based on the first test file and the first file integrity key, wherein the first value is used to verify the second file integrity key in the first subordinate node; The sending unit is further configured to: send the first value to the first subordinate node; The receiving unit is further configured to: receive the verification result of the second file integrity key sent by the first subordinate node.

17. The apparatus according to any one of claims 11-16, characterized in that, The receiving unit is further configured to: receive a first upgrade file when the first verification result indicates that the first node is in a normal state of use, and the second verification result indicates that the one or more subordinate nodes are in a normal state of use, wherein the first upgrade file is used for upgrading the first node and at least some of the one or more subordinate nodes.

18. The apparatus according to any one of claims 11-17, characterized in that, The receiving unit is further configured to: receive the first verification task and the first test file from the cloud server.

19. An inspection apparatus characterized by comprising: The device includes: Memory, used to store computer programs; A processor for executing a computer program stored in the memory to cause the apparatus to perform the method as described in any one of claims 1 to 9.

20. A vehicle characterized by comprising: Includes the apparatus as described in any one of claims 10 to 19.

21. A computer-readable storage medium, characterized in that, It stores instructions that, when executed by a processor, cause the processor to implement the method as described in any one of claims 1 to 9.

22. A computer program product, characterised in that, The computer program product comprises computer program code which, when the computer program code is run on a computer, causes the computer to implement the method of any one of claims 1 to 9.

23. A chip, characterized by The chip comprises circuitry for performing the method of any one of claims 1 to 9.

Images