Method of and related device of acquiring file based on wireless OTA technique

Abstract

To provide a method of, a vehicle for, a server for, a chip system for, and a storage medium for implementing file acquisition based on a wireless Over the Air (OTA) Technology and acquiring a file based on the OTA technology in order to simplify management of a file associated with a vehicle function.SOLUTION: A method of acquiring a file based on a wireless OTA technology has a step of acquiring a target request by a first vehicle. The target request has target service information. The target service information is used for acquiring a target file associated with a target function. The method also has steps of transmitting the target request to a server by the first vehicle, and receiving the target file requested by the target request by the first vehicle. The target file is used for indicating the first vehicle implementing the target function.SELECTED DRAWING: Figure 12A

Description

[Technical Field]

[0001] The present application relates to the field of in-vehicle technology, and in particular to a method and related device for obtaining files based on over-the-air (OTA) technology. [Background technology]

[0002] In the related art, when a vehicle needs to implement a specific service function, the vehicle needs to obtain a file corresponding to the service function from an external dedicated file server. Because a vehicle includes multiple components, and multiple pieces of software that implement different service functions may be installed in each component, managing files corresponding to different service functions of the vehicle using a file server is complicated and inefficient.

[0003] For example, a usage license file (a file used for software protection) can be used to enable a service function in a vehicle. The server provides a target file to the user, which controls the execution of the software, so that the software is used within the permitted scope. In this way, the vehicle implements customized functions. The generation, distribution, and management of target files for the entire vehicle are completed by a dedicated license server. Due to the complex internal structure of the vehicle, various service function modules, and different resource permissions, managing license files for the entire vehicle is complex. Summary of the Invention [Means for solving the problem]

[0004] Embodiments of the present application provide a method and associated device for implementing file retrieval based on over-the-air (OTA) technology and retrieving files based on OTA technology to simplify management of files associated with vehicle functions.

[0005] According to a first aspect, an embodiment of the present application provides a method for acquiring a file based on wireless OTA technology, the method includes:

[0006] the first vehicle obtains a target request, the target request including target service information, the target service information being used to obtain a target file associated with the target function; The first vehicle sends a targeting request to the server; The first vehicle receives the target file requested by the target request, and the target file is used to indicate to the first vehicle that the target function is to be implemented.

[0007] In the related art, when a vehicle needs to implement a specific service function, the vehicle needs to obtain a file corresponding to the service function from an external dedicated file server. Because a vehicle includes multiple components, each of which may have multiple software programs installed to implement different service functions, managing files corresponding to different service functions of the vehicle using a file server is complex and inefficient. In this embodiment of the present application, when a vehicle performs an OTA remote firmware / software upgrade based on related OTA technology, a remote upgrade channel is established between the server and the vehicle (including a master vehicle control unit and one or more slave vehicle units). The master vehicle control unit manages hardware information of each slave vehicle control unit and software version information corresponding to at least one piece of software installed on each slave vehicle control unit, and distributes software upgrade packages to each slave vehicle control unit. After receiving a target request containing target service information, the vehicle initiates a related request to the server by reusing the OTA remote upgrade channel between the server and the vehicle, and receives a target file associated with the target function and sent by the server based on OTA technology to implement the target function based on the target file. In this way, service-related files can be obtained based on OTA technology. In conclusion, in this application, the OTA remote upgrade channel between the server and the vehicle is reused to avoid the complex function-related file management caused by the need to create a file management channel and the need to use a dedicated file server to complete the generation, distribution, and management of function-related files across the vehicle. In addition, the user can purchase corresponding services for the vehicle based on their customized requirements. The user's customized requirements can be met, the purchase cost can be reduced, and the user experience can be improved.

[0008] In one possible implementation, the first vehicle sending the target request to the server includes the first vehicle sending the target request to the server using OTA technology.

[0009] In one possible embodiment, receiving the target file requested by the target request by the first vehicle includes receiving the target file requested by the target request by the first vehicle using OTA technology.

[0010] In one possible embodiment, the method further includes the steps of the first vehicle performing signature verification on the target file, and if the signature verification of the target file is successful, the first vehicle implementing a target function based on the target file.

[0011] The first vehicle in this embodiment of the present application may include a master vehicle control unit and one or more slave vehicle control units. The target function is a function to be implemented by a target slave vehicle control unit among the one or more slave vehicle control units. Specifically, the master vehicle control unit may perform signature verification on the target file. If the signature verification on the target file is successful, the master vehicle control unit transmits the target file to the target slave vehicle control unit. In this embodiment of the present application, once the signed target file obtained from outside the vehicle is verified, the first vehicle implements the target function based on the target file inside the first vehicle to ensure the security of implementing the target function of the first vehicle.

[0012] In one possible embodiment, the method further includes the steps of: the first vehicle checking the validity of the target file; and, if the validity check of the target file is successful, the first vehicle implementing the target function based on the target file.

[0013] In this embodiment of the present application, the first vehicle checks the validity of the target file in the master vehicle control unit or the target slave vehicle control unit. After the validity of the target file acquired from outside the vehicle is checked, the vehicle implements the target function based on the target file. In this way, a situation in which the target function cannot be implemented because the received target file is not a target file corresponding to the target function can be avoided, and the efficiency and security of implementing the target function of the first vehicle can be guaranteed.

[0014] In one possible embodiment, the target request further includes hardware information of the first vehicle, and the target file includes a device feature code generated based on the hardware information, and the step of the first vehicle checking the validity of the target file includes the step of the first vehicle determining whether the hardware information matches the device feature code, and determining that the target file is a valid file if the hardware information matches the device feature code.

[0015] The hardware information of the first vehicle included in the target request may be hardware information of a target slave vehicle control unit in the first vehicle. The target file includes a device feature code generated based on the hardware information of the slave vehicle control unit. The first vehicle determines whether the target file is valid by determining whether the hardware information of the target slave vehicle control unit matches the device feature code. In this embodiment of the present application, once the validity of the target file acquired from outside the vehicle is checked, the first vehicle implements the target function based on the target file. In this way, a situation in which the target function cannot be implemented because the received target file does not correspond to the target function can be avoided, and the efficiency and security of implementing the target function in the first vehicle can be ensured.

[0016] In one possible embodiment, the method further includes a step in which the first vehicle detects whether software corresponding to the target function is installed in the first vehicle based on the target service information and at least one software version information corresponding to the first vehicle.

[0017] In this embodiment of the present application, the at least one software version information corresponding to the first vehicle may be at least one software version information corresponding to at least one software installed in the target slave vehicle control unit. After obtaining the target service information, the first vehicle may determine whether software corresponding to the target function is installed in the target slave vehicle control unit based on the at least one software version information corresponding to the at least one software installed in the target slave vehicle control unit and the target service information, so as to further ensure the implementation of the target function.

[0018] In one possible embodiment, the method further includes a step in which, if software corresponding to the target function is not installed in the first vehicle, the first vehicle sends an installation package acquisition request for software corresponding to the target function to the server.

[0019] In this embodiment of the present application, if the software corresponding to the target function is not installed in the first vehicle, the first vehicle sends an installation package acquisition request for the software corresponding to the target function to a server having a master vehicle control unit, to further ensure the implementation of the target function after the software corresponding to the target function is installed in the vehicle.

[0020] In one possible embodiment, the method further comprises:

[0021] The first vehicle receives the installation package sent by the server based on the installation package acquisition request, performs signature verification on the installation package, and if the signature verification of the installation package is successful, based on the installation package, the first vehicle installs software corresponding to the target function, and implements the target function based on the software and the target file.

[0022] In this embodiment of the present application, the first vehicle may receive the installation package sent by the server based on the installation package acquisition request via the master vehicle control unit and perform signature verification on the installation package. If the signature verification is successful, the master vehicle control unit sends the installation package to the target slave vehicle control unit. The target slave vehicle control unit installs software corresponding to the target function based on the installation package and implements the target function based on the software and the target file. In this embodiment of the present application, once the software corresponding to the target function is installed on the target slave vehicle control unit, the target slave vehicle control unit implements the target function based on the software. In this way, the implementation of the target function can be guaranteed.

[0023] In one possible embodiment, the target request further includes at least one software version information corresponding to the first vehicle, and the method further includes a step of the first vehicle receiving an installation package of software corresponding to the target function sent by the server and performing signature verification on the installation package, wherein the installation package is sent by the server when the server detects that the software corresponding to the target function is not installed in the first vehicle based on the target service information and the software version information; and a step of installing the software corresponding to the target function in the first vehicle based on the installation package if the signature verification of the installation package is successful, and implementing the target function based on the software and the target file.

[0024] In this embodiment of the present application, when the target request further includes at least one software version information corresponding to the first vehicle, the target request is further used to indicate to the server whether software corresponding to the target function is installed in the target slave vehicle control unit of the vehicle based on the at least one software version information and the target service information. If the server detects that the software corresponding to the target function is not installed in the first vehicle, the server sends an installation package of the software corresponding to the target function to the vehicle. The first vehicle then installs the software corresponding to the target function based on the installation package and implements the target function based on the software corresponding to the target function and the target file to ensure implementation of the target function. The target file is delivered based on OTA technology, and the remote firmware / software upgrade channel between the server and the first vehicle is reused, avoiding the complex file management caused by the need to create a file management channel.

[0025] In one possible embodiment, the first vehicle includes a master vehicle control unit and one or more slave vehicle control units, the target function is a function to be implemented by a target slave vehicle control unit among the one or more slave vehicle control units, and the step of the first vehicle receiving the target file requested by the target request includes the steps of the master vehicle control unit receiving the target file requested by the target request, and the master vehicle control unit sending the target file to the target slave vehicle control unit, wherein the target file is used to indicate the target slave vehicle control unit that will implement the target function based on the target file.

[0026] In this embodiment of the present application, when a vehicle performs an OTA remote firmware / software upgrade based on the associated OTA technology, a remote upgrade channel is established between the server and the vehicle (including a master vehicle control unit and one or more slave vehicle units). The master vehicle control unit manages the hardware information of each slave vehicle control unit and software version information corresponding to at least one piece of software installed on each slave vehicle control unit, and distributes software upgrade packages to each slave vehicle control unit. After receiving a target request including target service information, the vehicle initiates a related request to the server by reusing the OTA remote upgrade channel between the server and the vehicle, and receives a target file associated with the target function and sent by the server based on the OTA technology. After receiving the target file sent by the server, the master vehicle control unit distributes the target file based on the hardware information of each slave vehicle control unit managed internally and the software version information corresponding to at least one piece of software installed on each slave vehicle control unit, so that the target slave vehicle control unit implements the target function based on the target file. In this way, service-related files are obtained based on the OTA technology. In conclusion, in this application, the OTA remote upgrade channel between the server and the vehicle is reused to avoid the complex function-related file management caused by the need to create a file management channel and the need to use a dedicated file server to complete the generation, distribution, and management of function-related files across the vehicle. In addition, the user can purchase corresponding services for the vehicle based on their customized requirements. The user's customized requirements can be met, the purchase cost can be reduced, and the user experience can be improved.

[0027] In one possible embodiment, the first vehicle further includes a human machine interface (HMI), and the first vehicle obtaining the target request includes the first vehicle obtaining the target request via the HMI.

[0028] In this embodiment of the present application, the user can subscribe to the target function through the HMI, which is convenient for the user.

[0029] In one possible embodiment, the method further includes a step in which the first vehicle transmits a status of the target function to the server, the status of the target function including whether the target function is implemented and / or the validity period of the target function.

[0030] In this embodiment of the present application, the target slave vehicle control unit may periodically transmit the status of the target function to the master vehicle control unit, and the master vehicle control unit may transmit the status of the target function to the server, so that the server can manage the target file distributed to the first vehicle. In addition, the master vehicle control unit may display the status of the target function to the user, so that the user can know the usage status of the target function, the validity period of the target function, etc. via the HMI.

[0031] In one possible embodiment, the target request further includes one or more of the validity period of the target function, hardware information of the first vehicle, and at least one software version information corresponding to the first vehicle, and the target file is generated by the server based on one or more of the target service information, the validity period of the target function, the hardware information, and the at least one software version information.

[0032] In this embodiment of the present application, a situation in which the target file delivered by the server is not for the target slave control unit or the current version information of the software corresponding to the target function is not available can be avoided. In this way, a situation in which the target function cannot be implemented can be avoided. When the server receives the target request, it generates a target file, hardware information, and software corresponding to the target function that matches the target function based on the hardware information of the first vehicle (i.e., the hardware information of the target slave vehicle control unit) and at least one piece of software version information corresponding to the first vehicle in the target request (i.e., at least one piece of software version information corresponding to at least one piece of software installed on the target slave vehicle control unit). In this way, it can be ensured that the target service implementation is efficient and well-targeted.

[0033] In this embodiment of the present application, the target file includes a usage license file for the target function.

[0034] In this embodiment of the present application, the server provides the user with a license file, which controls the execution of the software so that the software is used within the permitted scope and the vehicle can implement customized functions.

[0035] According to a second aspect, an embodiment of the present application provides a method for acquiring a file based on wireless OTA technology, the method includes:

[0036] The server receives a target request sent by the first vehicle, the target request including target service information, the target service information being used to obtain a target file associated with the target function; The server generates a corresponding target file based on the target request; The server sends the target file to the first vehicle, and the target file is used to indicate to the first vehicle that the target function should be implemented.

[0037] In the related art, when a vehicle needs to implement a specific service function, the vehicle needs to obtain a file corresponding to the service function from an external dedicated file server. Because a vehicle includes multiple components, each of which may have multiple software programs installed to implement different service functions, managing files corresponding to different service functions of the vehicle using a file server is complex and inefficient. In this embodiment of the present application, when a vehicle performs an OTA remote firmware / software upgrade based on related OTA technology, a remote upgrade channel is established between the server and the vehicle (including a master vehicle control unit and one or more slave vehicle units). The master vehicle control unit manages hardware information of each slave vehicle control unit and software version information corresponding to at least one piece of software installed on each slave vehicle control unit, and distributes software upgrade packages to each slave vehicle control unit. After receiving a target request including target service information, the vehicle initiates an associated request to the server by reusing the OTA remote upgrade channel between the server and the vehicle, and the server sends a target file associated with the target function to the first vehicle based on OTA technology. In this way, the first vehicle can implement the target function based on the target file, and service-related files can be obtained based on OTA technology. In conclusion, in this application, the OTA remote upgrade channel between the server and the vehicle is reused to avoid the complex function-related file management caused by the need to create a file management channel and the need to use a dedicated file server to complete the generation, distribution, and management of function-related files across the vehicle. In addition, the user can purchase corresponding services for the vehicle based on their customized requirements. The user's customized requirements can be met, the purchase cost can be reduced, and the user experience can be improved.

[0038] In one possible implementation, the server receiving the target request sent by the first vehicle includes the server receiving the target request sent by the first vehicle using OTA technology.

[0039] In one possible implementation, the server transmitting the target file to the first vehicle includes the server transmitting the target file to the first vehicle using OTA technology.

[0040] In one possible implementation, the method further comprises the step of the server signing the target file.

[0041] In one possible embodiment, the target request further includes at least one software version information corresponding to the first vehicle, and the method further includes a step of the server detecting whether software corresponding to the target function is installed in the first vehicle based on the at least one software version information and the target service information, and if the software corresponding to the target function is not installed in the first vehicle, the server sending an installation package of the software corresponding to the target function to the first vehicle, wherein the installation package is used to install the software corresponding to the target function in the first vehicle based on the installation package.

[0042] In one possible implementation, the target request further includes one or more of: a validity period of the target feature, hardware information of the first vehicle, and at least one software version information corresponding to the first vehicle.

[0043] In one possible embodiment, the server generating the corresponding target file based on the target request includes:

[0044] The server generates a device feature code based on hardware information of the first vehicle, the server generates resource control items and function control items based on at least one software version information corresponding to the first vehicle, and the server generates a target file based on target service information, the validity period of the target function, the device feature code, the resource control items, and the function control items.

[0045] In this embodiment of the present application, a situation in which the target file distributed by the server is not the target file for the first vehicle or the current version information of the software corresponding to the target function can be avoided. In this way, a situation in which the target function cannot be implemented can be avoided. When the server receives the target request, it generates a target file, hardware information, and software corresponding to the target function and installed on the target control unit based on the hardware information of the first vehicle (i.e., the hardware information of the target slave vehicle control unit) and at least one piece of software version information corresponding to the first vehicle in the target request (i.e., at least one piece of software version information corresponding to at least one piece of software installed on the target slave vehicle control unit). In this way, it can be ensured that the target service implementation is efficient and well-targeted.

[0046] In one possible embodiment, the method further includes a step in which the server receives a status of the target function transmitted by the first vehicle, the status of the target function including whether the target function is enabled and / or the validity period of the target function.

[0047] In one possible embodiment, the target file includes a usage license file for the target function.

[0048] According to a third aspect, an embodiment of the present application provides a method for acquiring a file based on wireless OTA technology. The method is applied to a first vehicle, and the first vehicle includes a master vehicle control unit and one or more slave vehicle control units. The method includes:

[0049] the master vehicle control unit obtains a target request, the target request including target service information, the target service information being used to obtain a target file associated with a target function, the target function being a function implemented by a target slave vehicle control unit of the one or more slave vehicle control units; The master vehicle control unit sends a target request to the server; the master vehicle control unit receives the target file requested by the target request; The master vehicle control unit sends a target file to a target slave vehicle control unit, and the target file is used to indicate to the target slave vehicle control unit which target function to implement based on the target file.

[0050] In one possible embodiment, the method further comprises:

[0051] The master vehicle control unit performs signature verification of the target file; If the signature verification of the target file is successful, the master vehicle control unit performs an operation to transmit the target file to the target slave vehicle control unit.

[0052] In one possible embodiment, the method further comprises:

[0053] The target slave vehicle control unit checks the validity of the target file, If the validity check of the target file is successful, the target slave vehicle control unit implements the target function based on the target file.

[0054] In one possible embodiment, the target request further includes hardware information of the target slave vehicle control unit, the target file includes a device feature code generated based on the hardware information, and the target slave vehicle control unit checking the validity of the target file includes:

[0055] The target slave vehicle control unit determines whether the hardware information matches the device feature code, and if the hardware information matches the device feature code, determines that the target file is a valid file.

[0056] In one possible embodiment, the method further comprises:

[0057] The master vehicle control unit detects whether software corresponding to the target function is installed in the target slave vehicle control unit based on the target service information and at least one piece of software version information corresponding to at least one piece of software installed in the target slave vehicle control unit of the first vehicle.

[0058] In one possible embodiment, the method further comprises:

[0059] If the software corresponding to the target function is not installed in the target slave vehicle control unit, the master vehicle control unit sends a request to the server to obtain an installation package of the software corresponding to the target function.

[0060] In one possible embodiment, the method further comprises:

[0061] The master vehicle control unit receives the installation package sent by the server based on the installation package acquisition request and performs signature verification on the installation package. If the signature verification of the installation package is successful, the master vehicle control unit sends the installation package to the target slave vehicle control unit. The target slave vehicle control unit installs software corresponding to the target function based on the installation package and implements the target function based on the software and target file.

[0062] In one possible embodiment, the target request further includes at least one software version information corresponding to the first vehicle.

[0063] The master vehicle control unit receives an installation package for the software corresponding to the target function sent by the server and performs signature verification on the installation package. The installation package is sent by the server when the server detects, based on the target service information and software version information, that the software corresponding to the target function is not installed in the first vehicle. If the signature verification of the installation package is successful, the master vehicle control unit sends the installation package to the target slave vehicle control unit. The target slave vehicle control unit installs the software corresponding to the target function based on the installation package and implements the target function based on the software and target file.

[0064] In one possible embodiment, the first vehicle further includes a human-machine interface, and the master vehicle control unit obtaining the target request includes:

[0065] The master vehicle control unit receives the target requirements through the human machine interface.

[0066] In one possible embodiment, the method further comprises:

[0067] The master vehicle control unit transmits the state of the target function to the server and / or the human-machine interface, the state of the target function including whether the target function is implemented and / or the validity period of the target function.

[0068] In one possible embodiment, the target request further includes one or more of the validity period of the target function, hardware information of the first vehicle, and at least one software version information corresponding to at least one software installed in the target slave vehicle control unit of the first vehicle, and the target file is generated by the server based on one or more of the target service information, the validity period of the target function, the hardware information, and the at least one software version information.

[0069] In one possible embodiment, the target file includes a usage license file for the target function.

[0070] According to a fourth aspect, an embodiment of the present application provides a vehicle, the vehicle comprising: an acquisition unit configured to acquire a target request, the target request including target service information, the target service information being used to acquire a target file associated with a target function; a sending unit configured to send a target request to a server; a receiving unit configured to receive a target file requested by the target request, the target file being used to indicate a vehicle that implements the target function; Includes:

[0071] In one possible embodiment, the obtaining unit is specifically configured to obtain a target request using OTA technology, the target request including target service information, and the target service information is used to obtain a target file associated with a target function.

[0072] In one possible embodiment, the sending unit is specifically adapted to send the target request to the server using OTA technology.

[0073] In one possible embodiment, the vehicle comprises: a signature verification unit configured to perform signature verification of the target file, wherein the vehicle implements a target function based on the target file if the signature verification of the target file is successful; Further includes:

[0074] In one possible embodiment, the vehicle comprises: a validity check unit configured to check the validity of the target file, wherein the vehicle implements the target function based on the target file if the validity check of the target file is successful; Further includes:

[0075] In one possible embodiment, the target request further includes hardware information of the vehicle, and the target file includes a device feature code generated based on the hardware information, and the validity check unit is particularly configured to determine whether the hardware information matches the device feature code, and if the hardware information matches the device feature code, determine that the target file is a valid file.

[0076] In one possible embodiment, the vehicle comprises: an installation detection unit configured to detect whether software corresponding to the target function is installed in the vehicle based on the target service information and at least one software version information corresponding to the vehicle; Further includes:

[0077] In one possible embodiment, the sending unit is further configured to send an installation package acquisition request for software corresponding to the target function to the server if the software corresponding to the target function is not installed in the vehicle.

[0078] In one possible embodiment, the vehicle comprises: a first installation unit configured to receive an installation package sent by the server based on the installation package acquisition request, perform signature verification on the installation package, and if the signature verification of the installation package is successful, install software corresponding to a target function based on the installation package, and implement the target function based on the software and the target file; Further includes:

[0079] In one possible embodiment, the target request further includes at least one software version information corresponding to the vehicle. a second installation unit configured to receive an installation package of software corresponding to the target function sent by the server and perform signature verification on the installation package, the installation package being sent by the server when the server detects that the software corresponding to the target function is not installed in the vehicle based on the target service information and the software version information; and if the signature verification of the installation package is successful, install the software corresponding to the target function based on the installation package and implement the target function based on the software and the target file. Further includes:

[0080] In one possible implementation, the vehicle includes a master vehicle control unit and one or more slave vehicle control units, the target function being a function implemented by a target slave vehicle control unit of the one or more slave vehicle control units. receiving a target file requested by the target request through the master vehicle control unit, and transmitting the target file to the target slave vehicle control unit through the master vehicle control unit, the target file being used to indicate the target slave vehicle control unit that should implement the target function based on the target file; It is specifically configured so that

[0081] In one possible embodiment, the vehicle further comprises a human-machine interface, the acquisition unit being particularly configured to acquire the target request via the human-machine interface.

[0082] In one possible implementation, the sending unit is further configured to send a status of the target function to the server, the status of the target function including whether the target function is enabled and / or the validity period of the target function.

[0083] In one possible embodiment, the target request further includes one or more of the validity period of the target function, hardware information of the vehicle, and at least one software version information corresponding to the vehicle, and the target file is generated by the server based on one or more of the target service information, the validity period of the target function, the hardware information, and the at least one software version information.

[0084] In one possible embodiment, the target file includes a usage license file for the target function.

[0085] According to a fifth aspect, an embodiment of the present application provides a server, the server comprising: a receiving unit configured to receive a target request transmitted by the first vehicle, the target request including target service information, the target service information being used to obtain a target file associated with a target function; a generating unit configured to generate a corresponding target file based on the target request; a sending unit configured to send a target file to a first vehicle, the target file being used to indicate to the first vehicle that the target function is to be implemented; Includes:

[0086] In one possible embodiment, the receiving unit is particularly adapted to receive a target request sent by the first vehicle using OTA technology.

[0087] In one possible embodiment, the sending unit is specifically configured to send the target file to the first vehicle using OTA technology.

[0088] In one possible embodiment, the server: A signing unit configured to sign the target file Further includes:

[0089] In one possible embodiment, the target request further includes at least one software version information corresponding to the first vehicle. The server further includes an installation detection unit configured to detect whether software corresponding to the target function is installed in the first vehicle based on the at least one software version information and the target service information.

[0090] The sending unit is further configured to: send an installation package of software corresponding to the target function to the first vehicle if the software corresponding to the target function is not installed in the first vehicle; and the installation package is used to install the software corresponding to the target function in the first vehicle based on the installation package.

[0091] In one possible implementation, the target request further includes one or more of: a validity period of the target feature, hardware information of the first vehicle, and at least one software version information corresponding to the first vehicle.

[0092] In one possible embodiment, the generating unit comprises: generating a device feature code based on hardware information of the first vehicle; Generate resource control items and function control items based on at least one software version information corresponding to the first vehicle; Generate target files based on target service information, target feature validity period, device feature code, resource control items, and feature control items It is specifically configured so that

[0093] In one possible implementation, the receiving unit is further configured to receive a status of the target function transmitted by the first vehicle, the status of the target function including whether the target function is enabled and / or the validity period of the target function.

[0094] In one possible embodiment, the target file includes a usage license file for the target function.

[0095] According to a sixth aspect, an embodiment of the present application provides a system for acquiring a file based on OTA technology. The system includes a server and a vehicle. The vehicle is a vehicle according to any one of the embodiments of the fourth aspect, and the server is a server according to any one of the embodiments of the fifth aspect.

[0096] According to a seventh aspect, the present application provides an apparatus for acquiring a file based on OTA technology. The apparatus for acquiring a file based on OTA technology has a function for implementing a method according to any one of the above-mentioned method embodiments for acquiring a file based on OTA technology. The function may be implemented by hardware, or may be implemented by the hardware executing corresponding software. The hardware or software includes one or more modules corresponding to the function.

[0097] According to an eighth aspect, the present application provides a vehicle. The vehicle includes a processor configured to support the vehicle in performing corresponding functions in the method for obtaining a file based on OTA technology provided in the first aspect. The vehicle may further include a memory coupled to the processor, the memory storing program instructions and data required for the vehicle. The vehicle may further include a communication interface used for communication between the vehicle and another device or a communication network.

[0098] According to a ninth aspect, the present application provides a master vehicle control unit. The master vehicle control unit includes a processor configured to support the master vehicle control unit in performing functions corresponding to those of the method for acquiring a file based on OTA technology provided in the third aspect. The master vehicle control unit may further include a memory coupled to the processor, the memory storing program instructions and data required for the master vehicle control unit. The master vehicle control unit may further include a communication interface used for communication between the master vehicle control unit and another device or a communication network.

[0099] According to a tenth aspect, the present application provides a slave vehicle control unit. The slave vehicle control unit includes a processor configured to support the slave vehicle control unit in performing functions corresponding to the slave vehicle control unit (or a target slave vehicle control unit) in the method for acquiring a file based on OTA technology provided in the third aspect. The slave vehicle control unit may further include a memory. The memory is coupled to the processor and stores program instructions and data required for the slave vehicle control unit. The slave vehicle control unit may further include a communication interface used for communication between the slave vehicle control unit and another device or a communication network.

[0100] According to an eleventh aspect, the present application provides a server. The server includes a processor configured to support the server in performing corresponding functions in the method for obtaining a file based on OTA technology provided in the second aspect. The server may further include a memory coupled to the processor, the memory storing program instructions and data required for the server. The server may further include a communication interface used for communication between the server and another device or a communication network.

[0101] According to a twelfth aspect, the present application provides a computer storage medium configured to store computer software instructions for use by the vehicle of the eighth aspect, the computer software instructions including a program designed to implement the aforementioned aspect.

[0102] According to a thirteenth aspect, the present application provides a computer storage medium configured to store computer software instructions for use by the server of the eleventh aspect, the computer software instructions including a program designed to implement the aforementioned aspect.

[0103] According to a fourteenth aspect, an embodiment of the present application provides a computer program, the computer program including instructions, which, when executed by a computer, cause the computer to perform steps of a method for obtaining a file based on OTA technology according to any implementation of the first aspect.

[0104] According to a fifteenth aspect, an embodiment of the present application provides a computer program, the computer program including instructions, which, when executed by a computer, cause the computer to perform steps of a method for obtaining a file based on OTA technology according to any implementation of the second aspect.

[0105] According to a sixteenth aspect, the present application provides a chip system, the chip system including a processor configured to implement the functionality in the aforementioned aspects, e.g., to support a vehicle or a server in receiving or processing data and / or information in the aforementioned manner.

[0106] In one possible design, the chip system further includes a memory configured to store program instructions and data required by the vehicle or server. The chip system may include the chip, or may include the chip and other discrete components.

[0107] In order to more clearly describe the technical solutions in the embodiments or background art of the present application, the following briefly describes the accompanying drawings for illustrating the embodiments or background art of the present application. [Brief explanation of the drawings]

[0108] [Figure 1] 1 is a schematic diagram of an application scenario of obtaining a file based on OTA technology according to an embodiment of the present application; FIG. [Figure 2] 1 is a schematic diagram of an application scenario of obtaining a file based on OTA technology according to an embodiment of the present application; FIG. [Figure 3] 1 is a schematic diagram of an application scenario of obtaining a file based on OTA technology according to an embodiment of the present application; FIG. [Figure 4] 1 is a diagram of the architecture of a system for obtaining files based on OTA technology according to one embodiment of the present application; [Figure 5] FIG. 2 is a schematic diagram of the structure of a master vehicle control unit according to an embodiment of the present application. [Figure 6] FIG. 2 is a schematic diagram of the structure of a slave vehicle control unit according to an embodiment of the present application. [Figure 7] 1 is a schematic diagram of the structure of a terminal device according to an embodiment of the present application; [Figure 8] FIG. 2 is an architecture diagram of another system for obtaining files based on OTA technology according to an embodiment of the present application. [Figure 9] 1 is a schematic diagram of a vehicle structure according to an embodiment of the present application; [Figure 10] FIG. 1 is a diagram of an OTA upgrade architecture in the related art according to an embodiment of the present application. [Figure 11A] 1 is a schematic flowchart of a method for obtaining a file based on OTA technology according to an embodiment of the present application; [Figure 11B] 1 is a schematic flowchart of a method for obtaining a file based on OTA technology according to an embodiment of the present application; [Figure 12A] 1 is a schematic flowchart of another method for obtaining a file based on OTA technology according to an embodiment of the present application. [Figure 12B] 1 is a schematic flowchart of another method for obtaining a file based on OTA technology according to an embodiment of the present application. [Figure 13] 10 is a schematic flowchart of yet another method for obtaining a file based on OTA technology according to an embodiment of the present application. [Figure 14A]10 is a schematic flowchart of yet another method for obtaining a file based on OTA technology according to an embodiment of the present application. [Figure 14B] 10 is a schematic flowchart of yet another method for obtaining a file based on OTA technology according to an embodiment of the present application. [Figure 15A] 10 is a schematic flowchart of yet another method for obtaining a file based on OTA technology according to an embodiment of the present application. [Figure 15B] 10 is a schematic flowchart of yet another method for obtaining a file based on OTA technology according to an embodiment of the present application. [Figure 16] 1 is a schematic diagram of a vehicle structure according to an embodiment of the present application; [Figure 17] 1 is a schematic diagram of a vehicle structure according to an embodiment of the present application; [Figure 18] FIG. 2 is a schematic diagram of the structure of a server according to an embodiment of the present application; [Figure 19] 1 is a schematic diagram of the structure of a device according to an embodiment of the present application; DETAILED DESCRIPTION OF THE INVENTION

[0109] Hereinafter, embodiments of the present application will be described with reference to the accompanying drawings in the embodiments of the present application.

[0110] In the specification, claims, and accompanying drawings of this application, terms such as "first," "second," "third," and "fourth" are intended to distinguish between different objects and do not indicate a particular order. Additionally, "include," "have," and any other variations thereof are intended to cover a non-exclusive inclusion. For example, a process, method, system, product, or device that includes a series of steps or units is not limited to the listed steps or units, but may optionally include additional steps or units that are not listed, or may optionally include additional steps or units that are specific to the process, method, product, or device.

[0111] The term "embodiment" as used herein means that a particular feature, structure, or characteristic described with reference to this embodiment may be included in at least one embodiment of the present application. Phrases appearing in various places in this specification may not necessarily refer to the same embodiment, and are not an independent or optional embodiment that does not intersect with another embodiment. Those skilled in the art will understand, either explicitly or implicitly, that the embodiments described herein can be combined with other embodiments.

[0112] As used herein, terms such as "component," "module," and "system" are used to refer to computer-related entities, hardware, firmware, a combination of hardware and software, software, or software running on it. For example, a component may be, but is not limited to, a process running on a processor, a processor, an object, an executable file, a thread of execution, a program, and / or a computer. As illustrated using the figures, both a computing device and an application running on a computing device may be a component. One or more components may reside within a process and / or thread of execution, and components may be located on one computer and / or distributed between two or more computers. Additionally, these components may execute from various computer-readable media that store various data structures. For example, components may communicate by using local and / or remote processes, based on signals having one or more data packets (e.g., data from two components interacting with another component in a local system, a distributed system, and / or in a network such as the Internet that interacts with other systems using signals).

[0113] To aid those skilled in the art in better understanding, some terms in this application will first be explained.

[0114] (1) Over-the-Air Technology (OTA) is a technology for remote firmware or software upgrades via the air interface in mobile communications. OTA is widely used for network upgrades of devices such as smart TVs, mobile phones, tablets, and set-top boxes. With the development of intelligent connected vehicles, OTA online upgrades have become an important function for vehicles.

[0115] (2) A telematics box, also known as a T-Box, is a compound word of telecommunications and information science, and can be literally defined as a service system that provides information using a computer system built into a vehicle such as an automobile, aircraft, ship, or train, wireless communication technology, satellite navigation equipment, or Internet technology for exchanging information such as text and voice. In other words, this service system connects the vehicle to the Internet via a wireless network and provides the vehicle owner with various information necessary for driving and daily life.

[0116] (3) An Electronic Control Unit (ECU) is a vehicle-specific microcomputer controller from a usage standpoint. Similar to a typical computer, an ECU includes a microprocessor (CPU), memory (ROM or RAM), input / output (I / O) interfaces, analog-to-digital (A / D) converters, shapers, and large-scale integrated circuits such as drives. The slave vehicle control unit in this embodiment of the present application is an ECU.

[0117] (4) The vehicle control unit (VCU) is the overall vehicle controller for an electric vehicle. The VCU is the powertrain controller of the electric vehicle's power system, responsible for coordinating components such as the engine, drive motor, gearbox, and power battery, thereby improving the vehicle's power performance, safety, and cost-effectiveness. The VCU is the core controller of the entire electric vehicle control system, controlling the starting, operation, movement, speed, and stopping of the electric vehicle's motor, as well as other electronic devices in the electric vehicle. As the core controller of the battery electric vehicle control system, the VCU is responsible for tasks such as data exchange, safety management, driver intent interpretation, and power stream management. The VCU collects signals from the motor control system, accelerator pedal signals, brake pedal signals, and other components, performs comprehensive analysis, determines and responds to the driver's driving intent, and monitors the operation of the controllers of lower-level components. The VCU plays an important role in normal vehicle operation, battery power braking and regeneration, network management, fault diagnosis and handling, and vehicle status monitoring.

[0118] (5) Human Machine Interface (HMI), also known as the human-machine interface or user interface, is a medium for interaction and information exchange between a system and a user, implementing the conversion between the internal form of information and a form acceptable to humans.

[0119] (6) The Controller Area Network (CAN) bus is the most widely used field bus in the world. Its high reliability and powerful error detection capabilities have attracted much attention, making it widely used in vehicle computer control systems and industrial environments with high ambient temperatures, strong electromagnetic radiation, and severe vibration. The CAN bus is a widely used field bus with great application prospects in fields such as industrial measurement and control and industrial automation. CAN is a serial communication bus network. Its advantages in data communication are reliability, real-time performance, and flexibility. For transparent design and flexible implementation, the CAN bus structure is divided into a physical layer and a data link layer (including a logical link control (LLC) sublayer and a medium access control (MAC) sublayer) according to the ISO / OSI standard model.

[0120] (7) The Transport Layer Security (TLS) protocol is used to provide confidentiality and data integrity between two communicating applications. The protocol includes two layers: the TLS Record Protocol and the TLS Handshake Protocol. The Transport Layer Security (TLS) protocol is used to ensure confidentiality and data integrity between two communicating applications.

[0121] (8) A terminal device may be a User Equipment (UE), a Station (ST) in a Wireless Local Area Network (WLAN), a mobile phone, a Wireless Local Loop (WLL) station, a Personal Digital Assistant (PDA) device, a handheld device with wireless communication capabilities, a computing device or another processing device connected to a wireless modem, or a wearable device, etc.

[0122] (9) License files are used to authorize the use of software services and to limit software usage, such as the validity period and maximum number of users. Software piracy and illegal use have become a major concern for software product developers. To protect intellectual property rights and prevent software piracy and illegal use, software protection technologies are used to control unauthorized use of software. Currently, widely used software protection technologies provide users with license files and use the license files to control software execution, ensuring that the software can be used within the authorized scope. In addition, some service function modules or the number of resource items that can be loaded can be controlled using license permissions.

[0123] To facilitate understanding of the embodiments of the present application, the following lists exemplary scenarios to which the method for obtaining files based on OTA technology of the present application is applied. The following description may include three scenarios:

[0124] Scenario 1: A user performs one-to-one management of a vehicle via a terminal device.

[0125] Please refer to FIG. 1. FIG. 1 is a schematic diagram of an application scenario for obtaining files based on OTA technology according to an embodiment of the present application. The application scenario includes a terminal device (for example, the terminal device is the smartphone in FIG. 1), a vehicle, and a server. The terminal device and the vehicle may communicate with each other via Bluetooth, NFC, Wi-Fi, a mobile network, etc., and the server and the terminal device or the vehicle may communicate with each other via Wi-Fi, a mobile network, etc. A one-to-one matching relationship may be established between the smartphone and the vehicle. For example, the vehicle's license plate or unique identifier is matched with the terminal device's identification card or valid account. After the matching is completed, the smartphone and the vehicle may cooperate to implement the method steps for obtaining files based on OTA technology provided in the present application. In this way, a user can subscribe to the vehicle's service through the smartphone to meet the user's customized requirements.

[0126] Scenario 2: A user performs one-to-many management of vehicles via a terminal device.

[0127] Please refer to FIG. 2. FIG. 2 is a schematic diagram of another application scenario for obtaining files based on OTA technology according to an embodiment of the present application. The application scenario includes a terminal device (e.g., the terminal device is a smartphone in FIG. 2), multiple vehicles, and a server. For the communication method in the application scenario, please refer to the communication method in FIG. 1. Details will not be repeated here. A one-to-many matching relationship may be established between a smartphone and vehicles. For example, one user may own and manage multiple vehicles simultaneously, or one user may manage vehicles belonging to multiple different users. For example, to implement an application scenario in which one device simultaneously manages multiple vehicles, an employee of a 4S shop may use a dedicated terminal device to update the systems of vehicles of the same model in the shop, or a user may use his / her terminal device to provide or manage target files for nearby vehicles that are in a matching relationship with his / her terminal device. This saves time, network transmission bandwidth, and storage resources. It should be understood that in one-to-many management, the terminal device needs to store related information of multiple vehicles in advance, or the multiple vehicles may authenticate the authorization of the multiple vehicles and the service relationship between the multiple vehicles and the terminal device to the terminal device.

[0128] Scenario 3: The user directly performs one-to-one management of the vehicle.

[0129] Please refer to Figure 3. Figure 3 is a schematic diagram of yet another application scenario for obtaining files based on OTA technology according to an embodiment of the present application. The application scenario includes a vehicle and a server. The server may communicate with the vehicle via Wi-Fi, a mobile network, etc. The user browses for new services and subscribes to services through the vehicle's HMI so that the vehicle meets the user's customized requirements.

[0130] It will be understood that the application scenarios of Figures 1, 2, and 3 are merely some exemplary implementations in embodiments of the present application, and application scenarios in embodiments of the present application include, but are not limited to, the application scenarios described above.

[0131] With reference to the aforementioned application scenario, the following will first describe a system architecture on which an embodiment of the present application is based. Please refer to FIG. 4. FIG. 4 is a schematic diagram of a system architecture (abbreviated as Architecture 1) for retrieving files based on OTA technology according to an embodiment of the present application. The method for retrieving files based on OTA technology provided in the present application can be applied to the system architecture. The system architecture includes a server 300, a vehicle 100, and a terminal device 200 (for example, the terminal device is the smartphone in FIG. 4). The vehicle 100 includes a master vehicle control unit (also referred to as an update master or OTA master) 101 and one or more slave vehicle control units (also referred to as update slaves or OTA slaves) 102. The one or more slave vehicle control units 102 may include an Electronic Control Unit (ECU) 1, an ECU 2, etc. The master vehicle control unit may be located in a vehicle component, such as a gateway and a telematics box (T-BOX). The system architecture shown in Figure 4 uses an example in which the master vehicle unit is located in the gateway. The gateway is a core component in the vehicle's electronic and electrical architecture. As the data exchange hub of the vehicle network, the gateway can route network data between different networks, such as Controller Area Network (CAN), Local Interconnect Network (LIN), Media Oriented System Transport (MOST), and FlexRay (i.e., the FlexRay vehicle network standard). The telematics box is mainly used to communicate with the outside of the vehicle, background systems, and mobile phone applications (APPs).

[0132] The master vehicle control unit 101 is configured to manage and assist in the implementation of functionality of software installed on multiple slave vehicle control units 102 .

[0133] The server 300 may be configured to obtain target files or installation packages of software from a developer, where the target files may be used by the vehicle to implement a function (or enable a service), and the installation packages are used to install the software.

[0134] The master vehicle control unit 101 is primarily responsible for communication with multiple slave vehicle control units 102, or for communication with the terminal device 200 in this application, and the main function of the master vehicle control unit 101 is to manage and assist the implementation of customized functions. The master vehicle control unit 101 is a logical entity and can be physically deployed in any powerful unit or module, for example, a Telematics box (also called Telematics), a Gateway, or a Vehicle Control Unit VCU.

[0135] The configuration of the master vehicle control unit 101 may be as shown in FIG. 5. FIG. 5 is a schematic diagram of the structure of the master vehicle control unit 101 according to an embodiment of the present application. The master vehicle control unit 101 may include a processor CPU, associated volatile memory (Random Access Memory, RAM) and non-volatile memory (Read-Only Memory, ROM), a memory configured to store a program for retrieving files based on OTA technology, and a network interface used to communicate with other in-vehicle devices via a CAN bus or another in-vehicle network. It should be understood that if the master vehicle control unit 101 is implemented on a telematics box, the master vehicle control unit 101 further requires a network interface for communicating with an external network. That is, the master vehicle control unit 101 needs to have powerful computing power and a large amount of resources to assist the slave vehicle control units in completing service subscriptions and needs to be trusted by other in-vehicle devices. In terms of logical architecture division, the master vehicle control unit 101 divides its architecture into a part for external vehicle communication and a part for in-vehicle communication.

[0136] The configuration of the slave vehicle control unit 102 or any slave vehicle control unit 102 (including the target slave vehicle control unit in this application) may be as shown in FIG. 6. FIG. 6 is a schematic diagram of the structure of the slave vehicle control unit 102 according to one embodiment of the present application. The slave vehicle control unit 102 may include a microcontroller, a CAN controller, and a transceiver. The slave vehicle control unit 102 communicates with an in-vehicle network such as a CAN bus via the transceiver. The CAN controller is configured to implement the CAN protocol. The microcontroller is configured to implement computing processes related to pre-application and post-application, for example, to implement relevant procedures of a method performed by the target slave vehicle control unit to obtain a file based on the OTA technology of the present application. Referring to the above schematic structure diagram, in this application, based on an in-vehicle network, such as a CAN bus, the slave vehicle control unit 102 receives the target file sent by the master vehicle control unit 101 through a transceiver, and implements the target function based on the target file in a microcontroller. For more specific functions, please refer to the description of the relevant functions of the target slave control unit 102 in the subsequent embodiments.

[0137] For the configuration of the terminal device 200, please refer to Figure 7. Figure 7 is a schematic diagram of the structure of a terminal device according to an embodiment of the present application. The terminal device 200 may include a processor CPU, associated volatile memory RAM and non-volatile memory ROM, a memory configured to store a program for obtaining files based on OTA technology, where the program for obtaining files based on OTA technology is used to implement vehicle service subscription, a wireless communication module configured to communicate with other devices (including a vehicle, an OTA server, etc.), and an audio input / output module, a button or touch input module, a display, etc. configured to provide display and input of an interaction control interface for obtaining files based on OTA technology. The terminal device 200 may correspond to the application scenarios of Figures 1 and 2.

[0138] It will be understood that the system architecture of Figure 4 is merely an exemplary implementation in the embodiments of the present application. The communication system architecture in the embodiments of the present application includes, but is not limited to, the communication system architectures described above.

[0139] Please refer to Figure 8. Figure 8 is a diagram of another system architecture (abbreviated as Architecture 2) according to an embodiment of the present application. The difference from the system architecture provided in Figure 1 is that the server 300 in this system architecture further includes a file server 300-1 and an OTA server 300-2.

[0140] The file server 300-1 is configured to obtain target files from the developer and transmit the target files to the OTA server 300-2.

[0141] The OTA server 300-2 is configured to receive the target file sent by the file server 300-1 and perform data interaction with the vehicle 100.

[0142] It will be understood that for other specific functions of the master vehicle control unit 101 and the multiple slave vehicle control units 102, reference is made to the description of the functional entities or units in the system architecture of Figure 4. Details will not be repeated here.

[0143] It is further understood that the system architecture in the present application may further include a developer. After the developed and tested target file is released on the firmware / software, the target file is distributed to the file server 300-1 and the OTA server 300-2. Corresponding embodiments will be described in detail in the following description.

[0144] It should be noted that the system architectures of Figures 4 and 8 are only two exemplary implementation forms in the embodiments of the present application. The communication system architectures in the embodiments of the present application include, but are not limited to, the system architectures described above.

[0145] 9 is a functional block diagram of a vehicle 100 according to one embodiment of the present application. The vehicle 100 may include various subsystems, such as a driving system 110, a sensor system 120, a control system 130, one or more peripheral devices 140, a power source 150, a computer system 160, and a user interface 170. Optionally, the vehicle 100 may include more or fewer subsystems, and each subsystem may include multiple components. Additionally, all subsystems and components of the vehicle 100 may be interconnected in a wired or wireless manner.

[0146] The traction system 110 may include components that power the vehicle 100 for movement. In one embodiment, the traction system 110 may include an engine 111, a transmission 112, an energy source 113, and wheels / tires 114. The engine 111 may be an internal combustion engine, an electric motor, an air-compression engine, or a combination of other types of engines, such as a hybrid engine formed by a gasoline engine and an electric motor, or a hybrid engine formed by an internal combustion engine and an air-compression engine. The engine 111 converts the energy source 113 into mechanical energy. Examples of the energy source 113 include gasoline, diesel, another petroleum-based fuel, propane, another compressed gas-based fuel, ethanol, solar panels, batteries, and another power source. The energy source 113 may also provide energy to other systems of the vehicle 100. The transmission 112 may transfer mechanical power from the engine 111 to the wheels 114. The transmission 112 may include a gearbox, a differential, and a drive shaft. In one embodiment, the transmission 112 may further include another device, such as a clutch. The drive shaft may include one or more shafts that may be coupled to one or more wheels 114.

[0147] The sensor system 120 may include several sensors that detect information about the vehicle 100's surrounding environment. For example, the sensor system 120 may include a positioning system 121 (which may be a GPS system, a BeiDou system, or another positioning system), an inertial measurement unit (IMU) 122, a radar 123, a laser range finder 124, and a camera 125. The sensor system 120 may further include sensors of the vehicle 100's internal systems being monitored (e.g., an onboard air quality monitor, a fuel gauge, and an oil temperature gauge). Sensor data from one or more of these sensors can be used to detect objects and their corresponding characteristics (such as position, shape, direction, and speed). Such detection and recognition are important functions for the safe operation of the vehicle 100. The positioning system 121 may be configured to estimate the vehicle 100's geographic location. The IMU 122 is configured to detect changes in the vehicle 100's location and direction of travel based on inertial acceleration. In one embodiment, IMU 122 may be a combination of an accelerometer and a gyroscope. Radar 123 may detect objects in the environment surrounding vehicle 100 by using radio signals. In some embodiments, in addition to detecting objects, radar 123 may also be further configured to detect the speed and / or direction of travel of the objects. Laser range finder 124 may detect objects in the environment in which vehicle 100 is located by using lasers. In some embodiments, laser range finder 124 may include one or more laser sources, a laser scanner, one or more detectors, and other system components. Camera 125 may be configured to capture multiple images of the environment surrounding vehicle 100. Camera 125 may be a still camera or a video camera.

[0148] The control system 130 controls the operation of the vehicle 100 and the components of the vehicle 100. The control system 130 may include various components, such as a steering system 131, a throttle 132, a braking unit 133, a computer vision system 134, a path control system 135, and an obstacle avoidance system 136. The steering system 131 is operable to adjust the direction of travel of the vehicle 100. For example, in one embodiment, the steering system 131 may be a steering wheel system. The throttle 132 is configured to control the operating speed of the engine 111, further controlling the speed of the vehicle 100. The braking unit 133 is configured to control and decelerate the vehicle 100. The braking unit 133 may use friction to reduce the rotational speed of the wheels 114. In another embodiment, the braking unit 133 may convert the kinetic energy of the wheels 114 into an electric current. The braking unit 133 may alternatively reduce the rotational speed of the wheels 114 in another manner to control the speed of the vehicle 100. The computer vision system 134 may be operated to process and analyze images captured by the camera 125 to recognize objects and / or features within the vehicle 100's environment. The objects and / or features may include traffic signals, road boundaries, and obstacles. The computer vision system 134 may use object recognition algorithms, structure from motion (SFM) algorithms, video tracking, and other computer vision techniques. In some embodiments, the computer vision system 134 may be configured to draw a map of the environment, track objects, estimate the object's speed, and the like. The path control system 135 is configured to determine a driving path for the vehicle 100. In some embodiments, the path control system 135 may determine the driving path for the vehicle 100 based on data from the sensor system 120 and one or more predetermined maps. The obstacle avoidance system 136 is configured to recognize, evaluate, avoid, or circumvent potential obstacles within the vehicle 100's environment.

[0149] Of course, in one example, control system 130 may additionally or alternatively include components other than those shown and described, or may not include some of the components described above.

[0150] Vehicle 100 interacts with external sensors, another vehicle, another computer system, or a user by using external devices 140. External devices 140 may include a wireless communication system 141, an onboard computer 142, a microphone 143, and / or a speaker 144.

[0151] In some embodiments, external device 140 provides a means for a user of vehicle 100 to interact with user interface 170. For example, onboard computer 142 may provide information to the user of vehicle 100. User interface 170 may further operate onboard computer 142 to receive input from the user. Onboard computer 142 may perform operations via a touch panel. In other cases, external device 140 may provide a means for vehicle 100 to communicate with another device located within the vehicle. For example, microphone 143 may receive audio (e.g., voice commands or other audio input) from the user of vehicle 100. Similarly, speaker 144 may output audio to the user of vehicle 100. Wireless communication system 141 may wirelessly communicate with one or more devices, either directly or via a communication network. For example, the wireless communication system 141 may use 3G cellular communications, such as Code Division Multiple Access (CDMA), Evolution-Data Optimized (EVD), Global System for Mobile Communications (GSM) / General packet radio service (GPRS), cellular communications based on the 4th generation mobile networks (4G), such as Long Term Evolution (LTE), or cellular communications based on the 5th generation mobile networks (5th generation wireless systems, 5th-Generation, or 5G). The wireless communication system 141 may communicate with a wireless local area network (WLAN) via Wi-Fi.In some embodiments, wireless communication system 141 may communicate directly with devices via infrared links, Bluetooth, or ZigBee. Various vehicle communication systems, such as other wireless protocols, for example, wireless communication system 141, may include one or more Dedicated Short Range Communications (DSRC) devices, which may include public and / or private data communications between vehicles and / or roadside stations.

[0152] Power source 150 may provide power to various components of vehicle 100. In one embodiment, power source 150 may be a rechargeable lithium-ion battery or a lead-acid battery. One or more battery packs of such batteries may be configured as the power source that provides power to the components of vehicle 100. In some embodiments, power source 150 and energy source 113 may be implemented together, such as in some battery electric vehicles.

[0153] Some or all of the functions of vehicle 100 are controlled by computer system 160. Computer system 160 may include at least one processor 161. Processor 161 executes instructions 163 stored on a non-transitory computer-readable medium, such as data storage device 162. Computer system 160 may be multiple computing devices providing distributed control of individual components or subsystems of vehicle 100.

[0154] Processor 161 may be any conventional processor, such as a commercially available central processing unit (CPU). Optionally, the processor may be a dedicated device, such as an application specific integrated circuit (ASIC) or another hardware-based processor. While FIG. 9 functionally illustrates the processor, memory, and other components of computer system 160 in the same block, those skilled in the art will understand that a processor, computer system, or memory may actually include multiple processors, computers, or memories, which may or may not be housed in the same physical housing. For example, memory may be a hard disk drive or other storage medium located in a different housing than computer system 160. Thus, reference to a processor or computer is understood to include reference to a set of processors or computers or memories, which may or may not operate in parallel. Unlike using a single processor to perform the steps described herein, some components, such as steering and deceleration components, may include respective processors. A processor performs only calculations related to the component's specific function.

[0155] In various aspects described herein, the processor may be located remotely from the vehicle and in wireless communication with the vehicle. In other aspects, some processes described herein are performed on a processor located inside the vehicle, while other processes are performed by a remote processor, including performing the steps necessary for a single operation.

[0156] In some embodiments, memory 162 may include instructions 163 (e.g., program logic) that may be executed by processor 161 to perform various functions of vehicle 100, including those described above. Memory 162 may also include additional instructions, including instructions for transmitting data to, receiving data from, interacting with, and / or controlling one or more of travel system 110, sensor system 120, control system 130, and peripheral devices 140.

[0157] In addition to instructions 163, data storage device 162 may also store data, such as software installation packages, target files, and other information, which may be used by vehicle 100 and computer system 160 when software is installed on vehicle 100 or when target functions are implemented.

[0158] User interface 170 is configured to provide information to or receive information from a user of vehicle 100. Optionally, user interface 170 may be included in one or more input / output devices in a set of peripheral devices 140, such as wireless communication system 141, on-board computer 142, microphone 143, and speaker 144.

[0159] Computer system 160 may control functions of vehicle 100 based on inputs received from various subsystems (e.g., cruise control system 110, sensor control system 120, and control control system 130) and user interface 170. For example, computer system 160 may generate target requests using target service information from external device 108. In some embodiments, computer system 160 is operable to provide control over many aspects of vehicle 100 and its subsystems.

[0160] Optionally, one or more of the aforementioned components may be separate from or associated with vehicle 100. For example, memory 162 may be partially or completely separate from vehicle 100. The aforementioned components may be communicatively coupled in a wired and / or wireless manner.

[0161] Optionally, the above components are merely examples. In actual applications, components in the above modules may be added or removed based on actual requirements. Figure 9 should not be construed as a limitation on the embodiments of the present application.

[0162] The vehicle 100 may be a car, truck, motorcycle, bus, boat, airplane, helicopter, lawn mower, recreational vehicle, playground vehicle, construction equipment, trolley, golf cart, train, pushcart, etc., which is not specifically limited in this embodiment of the application.

[0163] The master vehicle control unit 101 and the slave vehicle units 102 in this embodiment of the present application may be located separately in any subsystem of the vehicle 100 shown in FIG.

[0164] First, the technical problem to be solved and application scenarios are proposed in this application. In the related art, firmware / software upgrades for conventional in-vehicle devices require vehicle recall. Specifically, the vehicle is recalled to a designated location, such as a vehicle repair shop or 4S workshop, to upgrade the firmware / software using the following method. The following Solution 1 and Solution 2 are specific implementations.

[0165] Solution 1: Use the Joint Test Action Group (JTAG) interface or the Background Debugging Mode (BDM) interface to perform online programming or to perform programming after the in-vehicle device is disassembled. Specifically, this may include Method 1 and Method 2.

[0166] Method 1: First, use a personal computer (PC) to download the software to be upgraded to the burner, connect the burner to the writing tool, place the printed circuit board (PCB) of the vehicle electronic control system on the writing tool, align the printed circuit board with the download interface, and perform software writing when the burner is powered on.

[0167] Method 2: Downloading the program from the PC and the single-chip microcomputer. Connect the data cable in series to the PCB of the vehicle electronic control system, and operate the PC to directly download the program to the single-chip microcomputer.

[0168] The above-mentioned methods 1 and 2 have problems in that they require skilled personnel, are expensive, and are inconvenient to operate.

[0169] Solution 2: Flashing is performed based on the CAN bus On-Board Diagnostic (OBD) system.

[0170] Step 1: Enter refresh mode from the vehicle electronic system's normal application operating state (trigger an interrupt or diagnostic).

[0171] Step 2: Check the memory of the vehicle electronic controller chip to determine whether the correct application program is stored in the memory.

[0172] Step 3: If there is no correct application in the memory, download the application software from the diagnostic device, transmit the application software via the CAN bus, and refresh the application program in the flash (the refresh module is configured to initiate and guide the software writing).

[0173] Solution 2 has the problem of requiring skilled personnel and a long cycle.

[0174] In addition to the aforementioned solutions 1 and 2, remote upgrades can now be applied to some vehicles. For example, as shown in FIG. 10, an original equipment manufacturer (OEM) periodically and collectively upgrades all relevant vehicle firmware / software. The OTA server signs the upgrade package and distributes the signed upgrade package via a Transport Layer Security (TLS) secure channel. The master vehicle control unit downloads the upgrade package via the TLS secure channel, performs signature verification on the upgrade package, disassembles the upgrade package, and distributes the package to its corresponding slave vehicle control units. The slave vehicle control units receive the upgrade package from the master vehicle control unit. The master vehicle control unit prompts each slave vehicle control unit to install the upgrade package based on specific dependencies and a specific sequence to complete the remote software upgrade. A vehicle includes multiple components. An OTA upgrade of the entire vehicle involves upgrading multiple components, and a master vehicle control unit (also called an OTA Master module) is required to coordinate the component upgrades. The master vehicle control unit runs on a vehicle component (such as a GW or Tbox) and coordinates and controls the upgrade modules of other components (slave vehicle control units, or OTA Slave modules) to complete the entire vehicle upgrade.

[0175] However, when a vehicle needs to implement a specific service function, it needs to obtain a file corresponding to the service function from an external dedicated file server. In addition, because a vehicle includes multiple components, each of which may have multiple pieces of software installed to implement different service functions, managing files corresponding to different service functions in the vehicle using a file server is complex and inefficient. For example, a usage license file (a file used for software protection) may be used to enable a service function in the vehicle. The server provides a target file to the user, which controls the execution of the software, so that the software is used within the permitted scope. In this way, the vehicle implements customized functions. The generation, distribution, and management of target files for the entire vehicle are completed by a dedicated license server. Due to the vehicle's complex internal structure, various service function modules, and different resource permissions, managing target files for the entire vehicle is complex.

[0176] With reference to the embodiment of the method for obtaining files based on OTA technology provided in this application, the following will analyze and solve the technical problems proposed in this application.

[0177] Please refer to Figures 11A and 11B. Figures 11A and 11B are schematic flowcharts of a method for obtaining a file based on OTA technology according to an embodiment of the present application. The method may be applied to the system architecture of Figure 4 or Figure 8. With reference to Figures 11A and 11B, the following provides a description from the perspective of interactions between a server and a first vehicle. The server, the first vehicle, and the terminal device in this embodiment of the present application may be the server 300, the vehicle 100, and the terminal device 200 described in Figures 1 to 10. The method may include the following steps S201 to S203.

[0178] S201: A first vehicle obtains a target request, where the target request includes target service information, and the target service information is used to obtain a target file associated with a target function.

[0179] Specifically, the first vehicle may further include a human-machine interface (HMI), and the first vehicle may receive target service information via the HMI. The target function may be a service function to be enabled and applied by the first vehicle. The target service information describes the service function to be enabled and applied by the first vehicle. For example, the target service information may include a service identifier.

[0180] S202: The first vehicle sends a target request to the server.

[0181] In response, the server receives the target request sent by the first vehicle.

[0182] Before the first vehicle exchanges data with the server, the first vehicle and the server may perform configuration, such as configuring certificates and private keys. Based on the configuration information, a secure channel is established between the first vehicle and the server, such as a HyperText Transfer Protocol over Secure Socket Layer (HTTPs) secure channel, a Transport Layer Security (TLS) secure channel, or a Datagram Transport Layer Security (DTLS) secure channel. In this way, information can be securely transmitted between the first vehicle and the server.

[0183] Optionally, the first vehicle sends the target request to the server based on OTA technology. Sending the target request to the server based on OTA technology may be understood as the first vehicle sending the target request to the server by reusing an OTA remote upgrade channel between the server and the first vehicle.

[0184] S203: The first vehicle receives the target file requested by the target request, and the target file is used to indicate the first vehicle that implements the target function.

[0185] Correspondingly, upon receiving the target request sent by the first vehicle, the server may generate a corresponding target file based on the target request and send the target file to the first vehicle.

[0186] Optionally, the first vehicle may receive the target file requested by the target request based on OTA technology. Receiving the target file requested by the target request based on OTA technology may be understood as the first vehicle receiving the target file by reusing the OTA remote upgrade channel between the server and the first vehicle.

[0187] In the related art, when a vehicle needs to implement a specific service function, the vehicle needs to obtain a file corresponding to the service function from an external dedicated file server. Because a vehicle includes multiple components, each of which may have multiple software programs installed to implement different service functions, managing files corresponding to different service functions of the vehicle using a file server is complex and inefficient. In this embodiment of the present application, when a vehicle performs an OTA remote firmware / software upgrade using related OTA technology, a remote upgrade channel is established between the server and the vehicle (including a master vehicle control unit and one or more slave vehicle units). The master vehicle control unit manages hardware information of each slave vehicle control unit and software version information corresponding to at least one piece of software installed in each slave vehicle control unit, and distributes software upgrade packages to each slave vehicle control unit. After receiving a target request containing target service information, the vehicle initiates a related request to the server by reusing the OTA remote upgrade channel between the server and the vehicle, and receives a target file associated with the target function and sent by the server using OTA technology to implement the target function based on the target file. In this way, service-related files can be obtained using OTA technology. In conclusion, in this application, the OTA remote upgrade channel between the server and the vehicle is reused to avoid the complex function-related file management caused by the need to create a file management channel and the need to use a dedicated file server to complete the generation, distribution, and management of function-related files across the vehicle. In addition, the user can purchase corresponding services for the vehicle based on their customized requirements. The user's customized requirements can be met, the purchase cost can be reduced, and the user experience can be improved.

[0188] In one possible embodiment, the method further comprises the following steps:

[0189] S204: The server generates a corresponding target file based on the target request.

[0190] Specifically, after receiving the target request sent by the first vehicle, the server generates a target file corresponding to the target function based on the target request. The server in this embodiment of the present application may include an OTA server and a file server. The server may generate the corresponding target file based on the target request in the following manner. For example, upon receiving the target request sent by the first vehicle, the OTA server directly generates the corresponding target file based on the target request, or upon receiving the target request sent by the first vehicle, the OTA server forwards the target request to another file server, which generates the corresponding target file based on the target request and then sends the generated target file to the OTA server. The OTA server then sends the generated target file to the first vehicle.

[0191] In one possible embodiment, the method further comprises the following steps:

[0192] S205: The first vehicle implements the target function based on the target file.

[0193] Before implementing the target function based on the target file, the first vehicle may further detect whether software corresponding to the target function is installed in the first vehicle. If it detects that software corresponding to the target function has been installed in the first vehicle, the first vehicle implements the target function based on the target file. If it detects that software corresponding to the target function has not been installed in the first vehicle, the software corresponding to the target function needs to be installed first, and then the target function is implemented based on the target file.

[0194] In one possible embodiment, the method further comprises the following steps:

[0195] S206: The server signs the target file.

[0196] S207: The first vehicle performs signature verification on the target file.

[0197] If the signature verification of the target file is successful, the first vehicle executes step S205, that is, implements the target function based on the target file.

[0198] Specifically, before transmitting the target file to the first vehicle, the server may perform security processing on the target file. The security processing may be a signature processing, an encryption processing, or other security processing to prevent unauthorized changes to the target file. In this embodiment of the present application, once the signed target file obtained from outside the vehicle is verified, the first vehicle implements the target function based on the target file in the vehicle to ensure the security of vehicle service activation.

[0199] In one possible embodiment, the method further comprises the following steps:

[0200] S208: The first vehicle checks the validity of the target file.

[0201] If the validity check of the target file is successful, the first vehicle executes step S205, i.e., implements the target function based on the target file. Specifically, if the signature verification of the target file is successful, the first vehicle may further check the validity of the target file. If the validity check of the target file is successful, the first vehicle implements the target function based on the target file. Upon receiving the target file sent by the server, the first vehicle may first perform signature verification on the target file. If the signature verification of the target file is successful, the target file is imported, and the unique identification field of the first vehicle's hardware information is read and compared with the unique identification field included in the target file to determine whether the target file is valid. If the unique identification field in the first vehicle's hardware information matches or matches the unique identification field included in the target file, the validity check of the target file is successful. If the unique identification field in the first vehicle's hardware information does not match or match the unique identification field included in the target file, the validity check of the target file fails. In this embodiment of the present application, after the validity of the target file acquired from outside the first vehicle is checked, the first vehicle implements the target function based on the target file. In this way, a situation in which the target function cannot be implemented because the received target file is not a target file corresponding to the target function can be avoided, and the efficiency and security of vehicle service activation can be guaranteed.

[0202] In one possible embodiment, the target request further includes hardware information of the first vehicle, the target file includes a device feature code generated based on the hardware information, and the first vehicle checking the validity of the target file includes:

[0203] The first vehicle determines whether the hardware information matches the device feature code, and if the hardware information matches the device feature code, determines that the target file is a valid file.

[0204] In this embodiment of the present application, after the validity of the target file acquired from outside the vehicle is checked, the first vehicle implements the target function based on the target file. In this way, a situation in which the target function cannot be implemented because the received target file is not a target file corresponding to the target function can be avoided, and the efficiency and security of vehicle service activation can be guaranteed.

[0205] In one possible embodiment, the target file includes a usage license file for the target function.

[0206] The contents of the license file may include the software manufacturer, product name, product version, device feature code, expiration date, resource control items, function control items, signature, etc. The license file contains several control policies (e.g., license control items) used to control the execution of the software. The device feature code, expiration date, resource control items, and function control items included in the target file are license control items. The license technology can be used to flexibly control software functions and the amount of available resources. After the validity check of the target file is successful, the first vehicle can execute the software based on the control items in the target file to implement the target functions corresponding to the software.

[0207] Optionally, when the first vehicle obtains the service information of the target function, the first vehicle or the server determines whether software corresponding to the target function is installed in the first vehicle, i.e., whether an installation package of the software corresponding to the target function needs to be downloaded. The above-described embodiment is implemented when the first vehicle or the server determines that software corresponding to the target function is installed in the first vehicle. Hereinafter, with reference to steps S209 to S213, operations that need to be performed by the server or the first vehicle when it is determined that software corresponding to the target function is not installed in the first vehicle will be described. Optionally, steps S209 to S213 indicate that the determination of whether software corresponding to the target function is installed in the first vehicle is performed by the first vehicle. Optionally, when the determination of whether software corresponding to the target function is installed in the first vehicle is performed by the server, the target request further includes at least one software version information corresponding to the first vehicle. In this case, steps S209 and S210 may not be performed. The method may include the following steps S211 to S213.

[0208] In one possible embodiment, the first vehicle determines whether software corresponding to the target function is installed in the target slave vehicle control unit.

[0209] S209: The first vehicle detects whether software corresponding to the target function is installed in the first vehicle based on the target service information and at least one software version information corresponding to the first vehicle.

[0210] In one possible embodiment, the method further comprises:

[0211] S210: If the software corresponding to the target function is not installed in the first vehicle, the first vehicle sends an installation package acquisition request for the software corresponding to the target function to the server.

[0212] The installation package acquisition request may include a software identifier, software version information, and hardware information of the first vehicle.

[0213] In one possible embodiment, the method further comprises:

[0214] S211: The first vehicle receives the installation package sent by the server.

[0215] Specifically, upon receiving an installation package acquisition request sent by the first vehicle, the server may obtain the installation package from the developer and perform security processing such as signing or encryption on the installation package to prevent unauthorized modification of the installation package.

[0216] S212: The first vehicle performs signature verification on the installation package.

[0217] S213: If the signature verification of the installation package is successful, software corresponding to the target function is installed in the first vehicle based on the installation package.

[0218] When the software corresponding to the target function is installed in the first vehicle, the first vehicle implements the target function based on the software and the target file.

[0219] In one possible embodiment, the target request further includes at least one piece of software version information corresponding to the first vehicle. In this case, the method includes the aforementioned steps S211 to S213. Specifically, when the target request further includes at least one piece of software version information corresponding to the first vehicle, the server detects whether software corresponding to the target function is installed in the first vehicle based on the target service information and the software version information. If the server detects that software corresponding to the target function is not installed in the first vehicle based on the target service information and the software version information, the server sends an installation package for the software corresponding to the target function to the first vehicle. The first vehicle receives the installation package corresponding to the target function and performs signature verification on the installation package. If the signature verification of the installation package is successful, the software corresponding to the target function is installed in the first vehicle based on the installation package, and the target function is implemented based on the software and the target file.

[0220] In one possible implementation, the first vehicle includes a master vehicle control unit and one or more slave vehicle control units, and the target function is a function implemented by a target slave vehicle control unit of the one or more slave vehicle control units. Receiving the target file requested by the target request by the first vehicle includes:

[0221] The master vehicle control unit receives the target file requested by the target request, and the master vehicle control unit transmits the target file to the target slave vehicle control unit, and the target file is used to indicate to the target slave vehicle control unit which target function to implement based on the target file.

[0222] When the first vehicle includes a master vehicle control unit and one or more slave vehicle control units, for operations performed by the master vehicle control unit and one or more slave vehicle control units, please refer to the descriptions of the relevant steps in the embodiments corresponding to Figures 12A to 15B, and details will not be repeated here.

[0223] In one possible embodiment, the first vehicle further includes a human-machine interface, and the first vehicle obtaining the target request includes the first vehicle obtaining the target request via the human-machine interface.

[0224] In one possible embodiment, the method further comprises:

[0225] S214: The first vehicle sends the state of the target function to the server.

[0226] The state of the target feature includes whether the target feature is implemented and / or the lifetime of the target feature.

[0227] Specifically, the first vehicle may periodically transmit the status of the target function to the server so that the server can manage the distributed target file. In addition, the first vehicle may display the status of the target function to the user, so that the user can know the usage status and validity period of the target function through the HMI of the first vehicle.

[0228] In one possible embodiment, the target request further includes one or more of the validity period of the target function, hardware information of the first vehicle, and at least one software version information corresponding to the first vehicle, and the target file is generated by the server based on one or more of the target service information, the validity period of the target function, the hardware information, and the at least one software version information.

[0229] Optionally, the target request may further include an identification code of the vehicle.

[0230] Please refer to Figures 12A and 12B. Figures 12A and 12B are schematic flowcharts of a method for obtaining a file based on OTA technology according to an embodiment of the present application. This method may be applied to the system architecture of Figure 4 or Figure 8. Hereinafter, with reference to Figures 12A and 12B, a description will be provided in terms of interactions between a server, a master vehicle control unit of a first vehicle, and a target slave vehicle control unit of the first vehicle. The server, the master vehicle control unit of the first vehicle, the target slave vehicle control unit of the first vehicle, and the terminal device in this embodiment of the present application may be the server 300, the vehicle 100, the master vehicle control unit 101, the target slave vehicle control unit 102, and the terminal device 300 described in Figures 1 to 10. This method may include the following steps S301 to S305.

[0231] S301: A master vehicle control unit obtains a target request, the target request including target service information, the target service information is used to obtain a target file associated with a target function, the target function being a function implemented by a target slave vehicle control unit among one or more slave vehicle control units.

[0232] Specifically, the vehicle further includes a human-machine interaction interface (HMI). A user triggers the use or purchase of a service or function through the HMI, and the HMI receives target service information. The HMI transmits the user's target service information to the master vehicle control unit, where the target service information may include a service identifier. Optionally, the user may trigger the use or purchase of a service through a terminal device such as a smartphone. Upon receiving the user's purchase request for a service, the smartphone obtains the target service information and transmits the target service information to the HMI. The HMI then forwards the target service information to the master vehicle control unit. Alternatively, the smartphone may transmit the target service information directly to the master vehicle control unit. This is not limited to this embodiment of the present application.

[0233] S302: The master vehicle control unit sends a target request to the server.

[0234] Before the master vehicle control unit exchanges data with the server, the master vehicle control unit and the server may perform configuration, for example, configuring certificates and private keys. Based on the configuration information, a secure channel is established between the master vehicle control unit and the server, for example, a HyperText Transfer Protocol over Secure Socket Layer (HTTPs) secure channel, a Transport Layer Security (TLS) secure channel, or a Datagram Transport Layer Security (DTLS) secure channel. In this way, information can be securely transmitted between the master vehicle control unit and the server. Optionally, the target request may further include a vehicle identification code. This is not limited in this embodiment of the present application.

[0235] S303: The server generates a corresponding target file based on the target request.

[0236] Specifically, upon receiving a target request sent by the master vehicle control unit, the server generates a corresponding target file according to the target request, and the target file is used to indicate a target slave vehicle control unit that implements the target function based on the target file. The server in this embodiment of the present application may include an OTA server and a license server. The server may generate a corresponding target file based on the target request in the following manner: For example, upon receiving a target request sent by the master vehicle control unit, the OTA server directly generates a corresponding target file based on the target request; or, upon receiving a target request sent by the master vehicle control unit, the OTA server forwards the target request to a file server, which generates a corresponding target file based on the target request, and then sends the generated target file to the OTA server.

[0237] S304: The master vehicle control unit receives the target file requested by the target request.

[0238] Before transmitting the target file to the master vehicle control unit, the server may perform security processing on the target file. The security processing may be signing, encryption, or other security processing to prevent unauthorized changes to the target file. After receiving the target file, the master vehicle control unit may perform signature verification on the received target file.

[0239] S305: The master vehicle control unit sends a target file to a target slave vehicle control unit, and the target file is used to indicate the target slave vehicle control unit that will implement the target function based on the target file.

[0240] Specifically, upon receiving the target file sent by the server, the master vehicle control unit transmits the target file to a target slave vehicle control unit that has software corresponding to the target function turned on. Upon receiving the target file, the target vehicle control unit implements the target function based on the target file.

[0241] In the related art, when a vehicle needs to implement a specific service function, the vehicle needs to obtain a file corresponding to the service function from an external dedicated file server. Because a vehicle includes multiple components, each of which may have multiple software programs installed to implement different service functions, managing files corresponding to different service functions of the vehicle using a file server is complex and inefficient. In this embodiment of the present application, when a vehicle performs an OTA remote firmware / software upgrade using related OTA technology, a remote upgrade channel is established between the server and the vehicle (including a master vehicle control unit and one or more slave vehicle units). The master vehicle control unit manages hardware information of each slave vehicle control unit and software version information corresponding to at least one piece of software installed in each slave vehicle control unit, and distributes software upgrade packages to each slave vehicle control unit. After receiving a target request containing target service information, the vehicle initiates a related request to the server by reusing the OTA remote upgrade channel between the server and the vehicle, and receives a target file associated with the target function and sent by the server using OTA technology to implement the target function based on the target file. In this way, service-related files can be obtained using OTA technology. In conclusion, in this application, the OTA remote upgrade channel between the server and the vehicle is reused to avoid the complex function-related file management caused by the need to create a file management channel and the need to use a dedicated file server to complete the generation, distribution, and management of function-related files across the vehicle. In addition, the user can purchase corresponding services for the vehicle based on their customized requirements. The user's customized requirements can be met, the purchase cost can be reduced, and the user experience can be improved.

[0242] In one possible embodiment, the method further comprises:

[0243] S306: The server signs the target file.

[0244] S307: The master vehicle control unit performs signature verification on the target file.

[0245] If the signature verification is successful, the master vehicle control unit performs an operation to send the target file to the target slave vehicle control unit, ie, performs operation S305.

[0246] Before sending the target file to the master vehicle control unit, the server may perform security processing on the target file. The security processing may be a signature processing, an encryption processing, or other security processing, etc., to prevent unauthorized changes to the target file. Optionally, upon receiving the target file, the master vehicle control unit may directly perform signature verification on the target file, or may send the target file to the target slave vehicle control unit, and the target vehicle control unit performs signature verification. This is not limited in this embodiment of the present application.

[0247] In this embodiment of the present application, once the signed target file obtained from outside the vehicle is verified, the master vehicle control unit in the vehicle transmits the target file to the target slave vehicle control unit in the vehicle to ensure the security of the vehicle service activation.

[0248] In one possible embodiment, the method further comprises:

[0249] S308: The target slave vehicle control unit checks the validity of the target file.

[0250] S309: If the validity check of the target file is successful, the target slave vehicle control unit implements the target function based on the target file.

[0251] Upon receiving the target file sent by the master vehicle control unit, the target slave vehicle control unit imports the target file, reads the unique identification field in the hardware information of the target slave vehicle control unit, and compares the unique identification field with the unique identification field included in the target file to determine whether the target file is valid. If the unique identification field in the hardware information of the target slave vehicle control unit matches or matches the unique identification field included in the target file, the validity check of the target file is successful. If the unique identification field in the hardware information of the target slave vehicle control unit does not match or match the unique identification field included in the target file, the validity check of the target file fails. Optionally, the validity check of the target file may also be performed by the master vehicle control unit. That is, when the master vehicle control unit performs signature verification of the target file, if the signature verification is successful, the master vehicle control unit checks the validity of the target file. If the validity check of the target file is successful, the master vehicle control unit performs an operation of sending the target file to the target slave vehicle control unit. Upon receiving the target file, the target slave vehicle control unit directly implements the target function based on the target file.

[0252] In this embodiment of the present application, after the validity of the target file obtained from outside the vehicle is checked, the vehicle activates the target function based on the target file and uses the target function within the service validity period. In this way, the situation where the service activation fails because the received target file is not the target file corresponding to the target function can be avoided, and the efficiency and security of the vehicle function implementation can be guaranteed.

[0253] In one possible embodiment, the target request further includes hardware information of the target slave vehicle control unit, the target file includes a device feature code generated based on the hardware information of the slave vehicle control unit, and the target slave vehicle control unit can check the validity of the target file in the following manner: The target slave vehicle control unit determines whether the hardware information of the target slave vehicle control unit matches the device feature code, and determines that the target file is valid if the hardware information of the target slave vehicle control unit matches the device feature code.

[0254] Specifically, the target request sent by the master vehicle control unit to the server includes hardware information of the slave vehicle control unit corresponding to the target function. Upon receiving the target request, the server generates a device feature code based on the hardware information of the slave vehicle control unit included in the target request. The target slave vehicle control unit checks whether the target file is valid by determining whether the hardware information of the target slave vehicle control unit matches the device feature code.

[0255] In this embodiment of the present application, after the validity of the target file acquired from outside the vehicle is checked, the vehicle implements the target function based on the target file. In this way, a situation where the target function cannot be implemented because the received target file is not a target file corresponding to the target function can be avoided, and the efficiency and security of vehicle service activation can be guaranteed.

[0256] In one possible embodiment, the target file includes a usage license file for the target function.

[0257] The contents of the license file may include the software manufacturer, product name, product version, device feature code, expiration date, resource control items, function control items, signature, etc. The license file contains several control policies (e.g., license control items) used to control the execution of the software. The device feature code, expiration date, resource control items, and function control items included in the license file are license control items. The license technology can be used to flexibly control software functions and the amount of available resources. After the validity check of the license file is successful, the target slave vehicle control unit can execute the software based on the control items in the license file and enable the services that should be enabled corresponding to the software.

[0258] In one possible embodiment, the method further comprises the following steps:

[0259] S310: The target slave vehicle control unit sends a state of the target function to the master vehicle control unit, the state of the target function including whether the target function is implemented and / or the validity period of the target function.

[0260] S311: The master vehicle control unit sends the state of the target function to the server.

[0261] S312: The master vehicle control unit sends the state of the target function to the human machine interface.

[0262] Specifically, the target slave vehicle control unit may periodically transmit the status of the target function to the master vehicle control unit, and the master vehicle control unit may transmit the status of the target function to the server, so that the server can manage the distributed target file. In addition, the master vehicle control unit may transmit the status of the target function to the human-machine interface (HMI), so that the user can know the usage status and validity period of the service through the HMI.

[0263] In one possible embodiment, the method further comprises:

[0264] S313: The master vehicle control unit obtains hardware information of the target slave vehicle control unit and software version information corresponding to at least one software installed on the target slave vehicle control unit.

[0265] In one possible embodiment, the target request further includes one or more of the validity period of the target function, hardware information of the first vehicle, and at least one software version information corresponding to at least one software installed in the target slave vehicle control unit of the first vehicle, and the target file is generated by the server based on one or more of the target service information, the validity period of the target function, the hardware information, and the at least one software version information.

[0266] Optionally, before the master vehicle control unit sends the target request, the master vehicle control unit queries the hardware information of the target slave vehicle control unit and at least one software version information corresponding to the at least one software installed on the target slave vehicle control unit, and then sends the target request to the server, carrying the hardware information of the target slave vehicle control unit and the software version information corresponding to the at least one software installed on the target slave vehicle control unit. Upon receiving the target request, the server generates a target file matching the target function, the hardware information of the target vehicle control unit, and the software installed on the target control unit corresponding to the target function, based on the hardware information of the target slave vehicle control unit and the at least one software version information corresponding to the at least one software installed on the target slave vehicle control unit in the target request.

[0267] In one possible embodiment, when the target request further includes hardware information of the target slave vehicle control unit and software version information corresponding to at least one software installed on the target slave vehicle control unit, the server generating a corresponding target file based on the target request includes the server generating a device feature code based on the hardware information of the target slave vehicle control unit, the server generating resource control items and function control items based on the software version information corresponding to at least one software installed on the target slave vehicle control unit, and the server generating the target file based on the service information, device feature code, resource control items, and function control items of the target function.

[0268] Specifically, an example of a typical target file (eg, a license file) may be as shown in Table 1.

[0269] [Table 1]

[0270] In this embodiment of the present application, a situation in which the target file delivered by the server is not the target file for the target slave control unit, or the current version information of the software corresponding to the target function is not available, can be avoided. In this way, a situation in which the target function cannot be implemented can be avoided. Upon receiving a target request, the server generates a target file that matches the target function, the hardware information of the target vehicle control unit, and the software installed on the target control unit that corresponds to the target function, based on the hardware information of the target slave vehicle control unit and at least one piece of software version information corresponding to at least one piece of software installed on the target slave vehicle control unit in the target request. In this way, efficient and well-targeted service provisioning can be ensured.

[0271] Optionally, when the master vehicle control unit obtains the target service information, the master vehicle control unit or server determines whether software corresponding to the target function is installed on the target slave vehicle control unit, i.e., whether an installation package for the software corresponding to the target function needs to be downloaded. The above-described embodiment is implemented when the master vehicle control unit or server determines that software corresponding to the target function is installed on the target slave vehicle control unit. With reference to FIGS. 13, 14A, and 14B, operations that need to be performed by the server, master vehicle control unit, or target slave vehicle control unit when it is determined that software corresponding to the target function is not installed on the target slave vehicle control unit will be described. Steps S314 to S319, i.e., in FIG. 13, are performed by the master vehicle control unit to determine whether software corresponding to the target function is installed on the target slave vehicle control unit. Steps S320 to S325, i.e., in FIG. 13, are performed by the server to determine whether software corresponding to the target function is installed on the target slave vehicle control unit.

[0272] In one possible implementation, the master vehicle control unit determines whether software corresponding to the target function is installed on the target slave vehicle control unit. Below, with reference to Figures 12A and 12B, a description is provided in terms of interactions between the server, the vehicle's master vehicle control unit, and the vehicle's target slave vehicle control unit. The method may further include steps S314-S319.

[0273] The method further includes the following steps:

[0274] S314: The master vehicle control unit detects whether software corresponding to the target function is installed in the target slave vehicle control unit based on the target service information and software version information corresponding to at least one software installed in the target slave vehicle control unit.

[0275] Specifically, after obtaining hardware information of the target slave vehicle control unit and software version information corresponding to at least one software installed on the target slave vehicle control unit, the master vehicle control unit determines whether software corresponding to the target function is installed on the target slave vehicle control unit based on the software version information and the target service information.

[0276] S315: If the software corresponding to the target function is not installed in the target slave vehicle control unit, the master vehicle control unit sends a request to the server to obtain an installation package of the software corresponding to the target function.

[0277] Specifically, the installation package acquisition request may include a software identifier, software version information, and hardware information of the target slave vehicle control unit.

[0278] S316: The master vehicle control unit receives the installation package sent by the server based on the installation package acquisition request.

[0279] When the server receives the installation package acquisition request sent by the master vehicle control unit, it may acquire the installation package from the developer and perform security processing such as signing or encryption on the installation package to prevent unauthorized modification of the installation package.

[0280] S317: The master vehicle control unit performs signature verification on the installation package.

[0281] S318: If the signature verification is successful, the master vehicle control unit sends the installation package to the target slave vehicle control unit.

[0282] S319: The target slave vehicle control unit installs software corresponding to the target function based on the installation package.

[0283] In this embodiment of the present application, after obtaining the target service information, the master vehicle control unit obtains at least one software version information corresponding to at least one software installed in the target slave vehicle control unit corresponding to the target function, and determines whether the software corresponding to the target function is installed in the target slave vehicle control unit based on the target service information and the at least one software version information included in the service information. If it is determined that the software corresponding to the target function is not installed in the target slave vehicle control unit, the master vehicle control unit sends an installation package acquisition request for the software corresponding to the target function to the server. Once the software corresponding to the target function is installed in the target slave vehicle control unit, the target slave vehicle control unit implements the target function based on the software and the target file, ensuring that the service function subscribed by the user is successfully activated and used.

[0284] In one possible implementation, the server determines whether software corresponding to the target function is installed in the target slave vehicle control unit. Below, with reference to Figures 14A and 14B, a description is provided in terms of interactions between the server, the vehicle's master vehicle control unit, and the vehicle's target slave vehicle control unit. The method may further include steps S320-S325.

[0285] S320: The server detects whether software corresponding to the target function is installed in the target slave vehicle control unit based on the software version information and the target service information.

[0286] Specifically, the target request further includes hardware information of the target slave vehicle control unit and software version information corresponding to at least one software installed on the target slave vehicle control unit, and the target request is further configured to indicate a server that detects whether software corresponding to the target function is installed on the target slave vehicle control unit based on the software version information and the target service information.

[0287] If it is detected that the software corresponding to the target function is installed in the target slave vehicle control unit, the server performs an operation of sending the target file to the master vehicle control unit, and the master vehicle control unit performs an operation of receiving the target file sent by the server, that is, performs step S304. For specific operations, please refer to the relevant description of step S304. Details will not be repeated here.

[0288] If it is detected that the software corresponding to the target function is not installed in the vehicle, the server sends the target file and the installation package of the software corresponding to the target function to the master vehicle control unit. For the operation of the server sending the target file to the master vehicle control unit, please refer to the relevant description of step S304. Details will not be repeated here. Optionally, the step of the server sending the installation package of the software corresponding to the target function to the master vehicle control unit may include steps S321 to S323.

[0289] S321: If it is detected that software corresponding to the target function is not installed in the vehicle, the server sends service information of the target function and a policy package corresponding to the target file to the master vehicle control unit, where the policy package includes a download address of the installation package of the software corresponding to the target function, and the policy package is used by the master vehicle control unit to download the installation package according to the policy package.

[0290] Specifically, when the software version information corresponding to at least one piece of software installed in the target slave vehicle control unit detects whether it includes software corresponding to the target function, the server obtains an installation package corresponding to the target function, generates a target file and a policy package, and separately performs security processing on the installation package, target file, and policy package corresponding to the target function. The security processing may be a signature process, an encryption process, or other security processing to prevent unauthorized changes to the target file. The policy package may include the download address of the installation package corresponding to the target function, the implementation requirements of the target function, the size of the installation package or the target file, etc. This is not limited to this embodiment of the present application. For how the server generates the target file, please refer to step S303 and the related descriptions of target file generation in other embodiments. Details will not be repeated here.

[0291] S322: The master vehicle control unit performs signature verification on the policy package.

[0292] Specifically, for the process in which the master vehicle control unit performs signature verification on the policy package, please refer to the relevant description of signature verification on the target file in S307, and the details will not be repeated here.

[0293] S323: If the signature verification is successful, the master vehicle control unit downloads the installation package based on the policy package.

[0294] Specifically, if the signature verification is successful, the master vehicle control unit receives the target file sent by the server together with the policy package and downloads the installation package based on the policy package. There are multiple implementation methods for downloading the installation package and receiving the target file by the master vehicle control unit. For example, the installation package and the target file are downloaded and received simultaneously. Alternatively, the master vehicle control unit first downloads the installation package and then sends it to the target slave vehicle control unit. Once the installation package is installed on the target slave vehicle unit, the master vehicle control unit is notified and downloads and receives the target file. Once the target file is downloaded and received, the master vehicle control unit sends the target file to the target slave vehicle control unit, and the target slave vehicle control unit controls the execution of the software and the target function based on the target file. Alternatively, the master vehicle control unit first receives the target file, and if the signature verification and validity check of the target file are successful, the master vehicle control unit downloads the installation package. The subsequent operations in this embodiment of the present application, i.e., steps S322 and S323, will be described using an example in which the installation package and the license are downloaded simultaneously. When the installation package and the target file are not downloaded at the same time, the corresponding steps are separated and the details are not repeated here.

[0295] S324: The master vehicle control unit sends the installation package and the target file to the target slave vehicle control unit.

[0296] After receiving the target file and downloading the installation package based on the policy package, the master vehicle control unit may further separately perform signature verification on the installation package and the target file. If the signature verification is successful, the master vehicle control unit sends the installation package and the target file to the target slave vehicle control unit.

[0297] S325: The target slave vehicle control unit installs software corresponding to the target function based on the installation package, and implements the target function based on the target file.

[0298] Specifically, upon receiving the target file sent by the master vehicle control unit, the target slave vehicle control unit further checks the validity of the target file. If the target file validity check is successful, the target slave vehicle control unit implements the target function based on the target file. For the operation of the target slave vehicle control unit checking the validity of the target file, please refer to the relevant descriptions of S308 and S309 and the target slave vehicle control unit checking the validity of the target file in other embodiments. Details will not be repeated here.

[0299] In this embodiment of the present application, upon receiving the target request sent by the master control unit, the server determines whether software corresponding to the target function is installed in the target slave vehicle control unit based on the target service information and at least one software version information included in the target request. If the server determines that the software corresponding to the target function is not installed in the target slave vehicle control unit, it sends a policy package including the target file and the download address of the installation package to the master vehicle control unit. Once the software corresponding to the target function is installed in the target slave vehicle control unit, the target slave vehicle control unit enables the target function to ensure that the service subscribed by the user is successfully enabled and used.

[0300] In some other embodiments, as shown in FIGS. 15A and 15B, the vehicle may further include a file management unit. The file management unit may be located in the slave vehicle control unit or in another component of the vehicle. When the vehicle includes a file management unit, the file management unit may check the validity of the target file. If the validity check of the target file is successful, the file management unit indicates the target slave vehicle control unit that will implement the target function based on the target file. The file management unit may periodically send the status of the target function to the master vehicle control unit, which may then send the status of the target function to the server, so that the server can manage the distributed target file. Furthermore, the file management unit may send the status of the target function to the master vehicle control unit, which may then send the status of the target function to the HMI, allowing the user to know the usage status and validity period of the service through the HMI. Therefore, referring to FIGS. 12A, 12B, 14A, and 14B, when the vehicle may further include a file management unit, the method further includes the following steps:

[0301] S326: The target slave vehicle control unit sends the received target file to the file management unit.

[0302] S327: The file management unit checks the validity of the target file, and if the validity check is successful, executes step S309, i.e., enables the target function based on the target file and indicates the target slave vehicle control unit that will use the target function during the service validity period.

[0303] The embodiments corresponding to Figures 12A to 14B may be considered to be embodiments in which the file management unit is located in the slave vehicle control unit, i.e., ECU, of the vehicle, and the embodiments corresponding to Figures 15A and 15B may be considered to be embodiments in which the file management unit is located in another component of the vehicle other than the slave vehicle control unit.

[0304] The method in the embodiment of the present application is described above in detail. The related apparatus in the embodiment of the present application is provided below.

[0305] Please refer to Figure 16. Figure 16 is a schematic diagram of the structure of a vehicle 100 according to one embodiment of the present application. The vehicle 100 includes a master vehicle control unit 101 and one or more slave vehicle control units 102. The vehicle 100 may be the vehicle 100 in the aforementioned system. The master vehicle control unit 101 may be the master vehicle control unit 101 in the aforementioned system. The slave vehicle control unit 102 may be the slave vehicle control unit 102 in the aforementioned system. A detailed description of the units is as follows:

[0306] The master vehicle control unit 101 is configured to obtain a target request, the target request including target service information, the target service information being used to obtain a target file associated with a target function, the target function being a function implemented by a target slave vehicle control unit 102 among one or more slave vehicle control units 102, send the target request to a server, receive the target file requested by the target request, send the target file to the target slave vehicle control unit 102, and the target file being used to indicate the target slave vehicle control unit that will implement the target function based on the target file.

[0307] In one possible embodiment, the master vehicle control unit 101 is further configured to perform signature verification on the target file, and if the signature verification of the target file is successful, the master vehicle control unit 101 performs an operation of transmitting the target file to the target slave vehicle control unit 102.

[0308] In one possible embodiment, the target slave vehicle control unit 102 is further configured to check the validity of the target file, and the target slave vehicle control unit 102 implements the target function based on the target file if the validity check of the target file is successful.

[0309] In one possible embodiment, the target request further includes hardware information of the target slave vehicle control unit, the target file includes a device feature code generated based on the hardware information, and when configured to check the validity of the target file, the target slave vehicle control unit 102 is particularly configured to determine whether the hardware information matches the device feature code, and if the hardware information matches the device feature code, determine that the target file is a valid file.

[0310] In one possible embodiment, the master vehicle control unit 101 is further configured to detect whether software corresponding to the target function is installed in the target slave vehicle control unit 102 based on the target service information and at least one software version information corresponding to at least one software installed in the target slave vehicle control unit of the first vehicle.

[0311] In one possible embodiment, if the software corresponding to the target function is not installed in the target slave vehicle control unit 102, the master vehicle control unit 101 is further configured to send a request to the server to obtain an installation package of the software corresponding to the target function.

[0312] In one possible embodiment, the master vehicle control unit 101 is further configured to receive the installation package sent by the server based on the installation package acquisition request, perform signature verification on the installation package, and if the signature verification of the installation package is successful, send the installation package to the target slave vehicle control unit 102. The target slave vehicle control unit 102 is further configured to install software corresponding to the target function based on the installation package, and implement the target function based on the software and the target file.

[0313] In one possible embodiment, the target request further includes at least one software version information corresponding to the first vehicle. The master vehicle control unit 101 is further configured to receive an installation package of software corresponding to the target function sent by the server, perform signature verification on the installation package, the installation package being sent by the server when the server detects that the software corresponding to the target function has not been installed in the first vehicle (a target slave vehicle control unit in the vehicle) based on the target service information and the software version information, and send the installation package to the target slave vehicle control unit 102 if the signature verification of the installation package is successful. The target slave vehicle control unit 102 is configured to install the software corresponding to the target function based on the installation package, and implement the target function based on the software and the target file.

[0314] In one possible implementation, the first vehicle further comprises a human-machine interface 103. When configured to obtain target requests, the master vehicle control unit 101 is particularly configured to obtain the target requests via the human-machine interface 103.

[0315] In one possible implementation, the master vehicle control unit 101 is further configured to send a status of the target function to the server and / or the human machine interface 103, the status of the target function including whether the target function is implemented and / or the validity period of the target function.

[0316] In one possible embodiment, the target request further includes one or more of the validity period of the target function, hardware information of the first vehicle, and at least one software version information corresponding to at least one software installed in the target slave vehicle control unit of the first vehicle, and the target file is generated by the server based on one or more of the target service information, the validity period of the target function, the hardware information, and the at least one software version information.

[0317] In one possible embodiment, the target file includes a usage license file for the target function.

[0318] For the master vehicle control unit 101 and target slave vehicle control unit 102 in the vehicle 100 described in this embodiment of the present application, please refer to the relevant description of the master vehicle control unit and slave vehicle control unit in the method embodiment of Figures 12A to 15B, and details will not be repeated here.

[0319] It should be understood that functions such as an intelligent driving system, a life service system, a safety protection system, a positioning service system, a vehicle service system, etc. may be further integrated into the vehicle 100 by using technologies such as computers, advanced sensing, information convergence, communication, artificial intelligence, and automatic control, which are not particularly limited in this application and will not be described in detail herein.

[0320] Please refer to Figure 17. Figure 17 is a schematic diagram of the structure of another vehicle 100 according to an embodiment of the present application. The vehicle 100 may be the vehicle 100 in the aforementioned system. The vehicle 100 may include an acquiring unit 401, a transmitting unit 402, and a receiving unit 403. A detailed description of the units is as follows:

[0321] The acquiring unit 401 is configured to acquire a target request, where the target request includes target service information, and the target service information is used to acquire a target file associated with a target function.

[0322] The sending unit 402 is configured to send the target request to the server.

[0323] The receiving unit 403 is configured to receive a target file requested by the target request, where the target file is used to indicate a vehicle that implements the target function.

[0324] In one possible embodiment, the acquiring unit 401 is specifically configured to acquire a target request using OTA technology, where the target request includes target service information, and the target service information is used to acquire a target file associated with a target function.

[0325] In one possible embodiment, the sending unit 402 is specifically configured to send the target request to the server using OTA technology.

[0326] In one possible embodiment, the vehicle comprises: a signature verification unit 404 configured to perform signature verification of the target file, wherein the vehicle implements a target function based on the target file if the signature verification of the target file is successful; Further includes:

[0327] In one possible embodiment, the vehicle 100 includes: a validity check unit 405 configured to check the validity of the target file, and the vehicle implements the target function based on the target file if the validity check of the target file is successful; Further includes:

[0328] In one possible embodiment, the target request further includes hardware information of the vehicle, and the target file includes a device feature code generated based on the hardware information, and the validity check unit 405 is specifically configured to determine whether the hardware information matches the device feature code, and if the hardware information matches the device feature code, determine that the target file is a valid file.

[0329] In one possible embodiment, the vehicle 100 includes: an installation detection unit 406 configured to detect whether software corresponding to the target function is installed in the vehicle based on the target service information and at least one software version information corresponding to the vehicle; Further includes:

[0330] In one possible embodiment, the sending unit 402 is further configured to send an installation package acquisition request for software corresponding to the target function to the server if the software corresponding to the target function is not installed in the vehicle.

[0331] In one possible embodiment, the vehicle 100 includes: a first installation unit 407 configured to receive an installation package sent by the server based on the installation package acquisition request, perform signature verification on the installation package, and if the signature verification of the installation package is successful, install software corresponding to a target function based on the installation package, and implement the target function based on the software and the target file; Further includes:

[0332] In one possible embodiment, the target request further includes at least one software version information corresponding to the vehicle. a second installation unit 408 configured to receive an installation package of software corresponding to the target function sent by the server, and perform signature verification on the installation package, where the installation package is sent by the server when the server detects that the software corresponding to the target function is not installed in the vehicle based on the target service information and the software version information; and if the signature verification of the installation package is successful, install the software corresponding to the target function based on the installation package, and implement the target function based on the software and the target file. Further includes:

[0333] In one possible embodiment, the vehicle includes a master vehicle control unit and one or more slave vehicle control units, the target function is a function to be implemented by a target slave vehicle control unit among the one or more slave vehicle control units, the receiving unit 403 is particularly configured to receive a target file requested by the target request via the master vehicle control unit and transmit the target file to the target slave vehicle control unit via the master vehicle control unit, and the target file is used to indicate the target slave vehicle control unit that will implement the target function based on the target file.

[0334] In one possible embodiment, the vehicle further includes a human-machine interface. The obtaining unit 401 is specifically configured to obtain the target request via the human-machine interface.

[0335] In one possible implementation, the sending unit 402 is further configured to send a status of the target function to the server, where the status of the target function includes whether the target function is implemented and / or the validity period of the target function.

[0336] In one possible embodiment, the target request further includes one or more of the validity period of the target function, hardware information of the vehicle, and at least one software version information corresponding to the vehicle, and the target file is generated by the server based on one or more of the target service information, the validity period of the target function, the hardware information, and the at least one software version information.

[0337] In one possible embodiment, the target file includes a usage license file for the target function.

[0338] It should be noted that for the functions of the functional units in the vehicle described in this embodiment of the present application, reference may be made to the relevant descriptions of the aforementioned method embodiments in Figures 11A to 15B, and the details will not be repeated here.

[0339] Please refer to Figure 18. Figure 18 is a schematic diagram of the structure of a server 300 according to an embodiment of the present application. The server 300 may be the server 300 in the aforementioned system. The server may include a receiving unit 501, a generating unit 502, and a sending unit 503. A detailed description of the units is as follows:

[0340] The receiving unit 501 is configured to receive a target request sent by the first vehicle, the target request including target service information, and the target service information is used to obtain a target file associated with a target function.

[0341] The generating unit 502 is configured to generate a corresponding target file based on the target request.

[0342] The sending unit 503 is configured to send the target file to the first vehicle, where the target file is used to indicate the first vehicle that implements the target function.

[0343] In one possible implementation, the receiving unit 501 is specifically configured to receive a target request sent by the first vehicle using OTA technology.

[0344] In one possible embodiment, the sending unit 503 is specifically configured to send the target file to the first vehicle using OTA technology.

[0345] In one possible implementation, the server 300 further comprises a signing unit 504 configured to sign the target file.

[0346] In one possible embodiment, the target request further includes at least one software version information corresponding to the first vehicle. The server 300 further includes an installation detection unit 505 configured to detect whether software corresponding to the target function is installed in the first vehicle based on the at least one software version information and the target service information.

[0347] The sending unit 503 is further configured to: if the software corresponding to the target function is not installed in the first vehicle, send an installation package of the software corresponding to the target function to the first vehicle, and the installation package is used to install the software corresponding to the target function in the first vehicle based on the installation package.

[0348] In one possible implementation, the target request further includes one or more of: a validity period of the target feature, hardware information of the first vehicle, and at least one software version information corresponding to the first vehicle.

[0349] In one possible implementation, the generating unit 502 comprises: generating a device feature code based on hardware information of the first vehicle; Generate resource control items and function control items based on at least one software version information corresponding to the first vehicle; Generate target files based on target service information, target feature validity period, device feature code, resource control items, and feature control items It is specifically configured so that

[0350] In one possible implementation, the receiving unit 501 is further configured to receive a status of the target function transmitted by the first vehicle, the status of the target function including whether the target function is enabled and / or the validity period of the target function.

[0351] In one possible embodiment, the target file includes a usage license file for the target function.

[0352] It should be noted that for the functions of the functional units in the server described in this embodiment of the present application, reference may be made to the relevant descriptions of the foregoing method embodiments in Figures 11A to 15B, and the details will not be repeated here.

[0353] Please refer to Figure 19. Figure 19 is a schematic diagram of the structure of a device according to one embodiment of the present application. The vehicle and the server may be implemented using the structure of Figure 19. The device 60 includes at least one processor 601, at least one memory 602, and at least one communication interface 603. In addition, the device may further include general-purpose components such as an antenna. Details will not be described herein.

[0354] The processor 601 may be a general-purpose central processing unit (CPU), a microprocessor, an application-specific integrated circuit (ASIC), or one or more integrated circuits configured to control the execution of the programs of the solutions of the present application.

[0355] The communication interface 603 is used to communicate with another device or communication network, for example, an OTA server, a key server, or an in-vehicle device.

[0356] The memory 602 may be, without limitation, read-only memory (ROM) or another type of static storage device capable of storing static information and instructions, random access memory (RAM) or another type of dynamic storage device capable of storing information and instructions, or electrically erasable programmable read-only memory (EEPROM), compact disc read-only memory (CD-ROM) or other compact disc storage, optical disc storage (including compressed optical discs, laser discs, optical discs, digital versatile optical discs, Blu-ray discs, etc.), magnetic disc storage media or other magnetic storage devices, or any other medium that can be used to carry or store expected program code in the form of instructions or data structures and that can be accessed by a computer. The memory may exist independently or be connected to the processor via a bus. Alternatively, the memory may be integrated with the processor.

[0357] The memory 602 is configured to store application program code for implementing the aforementioned solution, and the processor 601 controls the execution of the application program code. The processor 601 is configured to execute the application program code stored in the memory 602.

[0358] 19 is a vehicle 100, the code stored in memory 602 may be used to execute the method for retrieving a file based on the OTA technology provided in Figures 11A-15B. For example, the method may include the steps of: receiving a target request, where the target request includes target service information, and the target service information is used to retrieve a target file associated with a target function; sending the target request to a server; and receiving the target file requested by the target request, where the target file is used to indicate a first vehicle that implements the target function.

[0359] It should be noted that for the functions of the functional units in the vehicle described in this embodiment of the present application, reference may be made to the relevant descriptions of the operations performed by the first vehicle in the aforementioned method embodiment of Figures 11A-15B, and the details will not be repeated here.

[0360] 19 is server 300, the code stored in memory 602 may be used to execute the method for obtaining a file based on the OTA technique provided in Figures 11A-15B. For example, the method may include receiving a target request sent by a first vehicle, the target request including target service information, the target service information being used to obtain a target file associated with a target function; generating a corresponding target file based on the target request; and transmitting the target file to the first vehicle, the target file being used to indicate to the first vehicle that the target function is implemented.

[0361] It should be noted that for the functions of the functional units in the server described in this embodiment of the present application, reference may be made to the relevant descriptions of the operations performed by the server in the above-described method embodiments in Figures 11A to 15B, and the details will not be repeated here.

[0362] An embodiment of the present application further provides a computer storage medium, which may store a program, and when the program is executed, may perform some or all of the steps of the method for obtaining a file based on OTA technology in the above-described method embodiment.

[0363] An embodiment of the present application further provides a computer program, which includes instructions, and when the computer program is executed by a computer, the computer may perform some or all of the steps of a method for obtaining a file based on OTA technology.

[0364] An embodiment of the present application further provides a system for obtaining a file based on OTA technology. The system includes a server and a vehicle. The vehicle is any vehicle according to the embodiments corresponding to Figures 16 and 17. The server is any server according to the embodiments corresponding to Figure 18.

[0365] An embodiment of the present application further provides a chip system, which includes a processor configured to implement the functionality in the aforementioned aspects, for example, to support a vehicle or a server in receiving or processing data and / or information in the aforementioned manner.

[0366] In one possible design, the chip system further includes a memory configured to store program instructions and data required by the vehicle or server. The chip system may include the chip, or may include the chip and other discrete components.

[0367] In the above embodiments, the description of each embodiment focuses on its own specifics, and for the parts not described in detail in one embodiment, please refer to the relevant descriptions of other embodiments.

[0368] It should be noted that for simplicity of explanation, the foregoing method embodiments are depicted as a series of operations. However, those skilled in the art should understand that the present application is not limited to the order of operations described, as some steps may be performed in other orders or simultaneously. It should be further understood by those skilled in the art that the embodiments described herein are exemplary embodiments, and the operations and modules involved are not necessarily required for the present application.

[0369] In some embodiments provided in the present application, it should be understood that the disclosed devices may be implemented in other ways. For example, the described device embodiments are merely examples. For example, the division into units is merely a logical division of function, and other divisions may be used in actual implementations. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not implemented. Furthermore, the shown or discussed mutual or direct couplings or communication connections may be implemented via some interfaces. Indirect couplings or communication connections between devices or units may be implemented in electronic or other forms.

[0370] The aforementioned units described as separate parts may or may not be physically separate. The parts shown as units may or may not be physical units, in other words, they may be located in one place or distributed over multiple network units. Some or all of the units may be selected based on actual requirements to achieve the objectives of the solutions of the embodiments.

[0371] In addition, the functional units in the embodiments of the present application may be integrated into one processing unit, or each unit may exist physically alone, or two or more units may be integrated into one unit. The integrated unit may be implemented in the form of hardware or in the form of a software functional unit.

[0372] When the above-mentioned integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, the integrated unit may be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application may essentially be implemented in the form of a software product, or a portion of the technical solution may be implemented in the form of a software product. The computer software product is stored in a storage medium and includes instructions for instructing a computer device (which may be a personal computer, a server, or a network device, specifically a processor within the computer device) to perform all or part of the steps of the method described in the embodiments of the present application. The aforementioned storage medium may include any medium capable of storing program code, such as a USB flash drive, a removable hard disk, a magnetic disk, an optical disk, a read-only memory (ROM), or a random access memory (RAM).

[0373] Finally, the foregoing embodiments are only intended to illustrate the technical solutions of the present application, and are not intended to limit the present application. Although the present application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some technical features thereof, without departing from the spirit and scope of the technical solutions of the embodiments of the present application. [Explanation of symbols]

[0374] 100 vehicles 101 Master vehicle control unit 102 Slave vehicle control unit 103 Human-Machine Interface 110 Running System 111 Engine 112 Transmission 113 Energy Sources 114 Wheels 120 Sensor System 121 Positioning System 122 Inertial Measurement Unit 123 Radar 124 Laser Rangefinder 125 Camera 130 Control System 131 Steering System 132 Throttle 133 Braking Unit 134 Computer Vision Systems 135 Routing Control System 136 Obstacle Avoidance System 140 Peripheral Devices 141 Wireless Communication Systems 142 In-vehicle computer 143 Microphone 144 Speaker 150 Power supply 160 Computer Systems 161 processors 162 memory 163 Command 170 User Interface 200 terminal devices 300 servers 300-1 File server 300-2 OTA Server 401 Acquired Units 402 Transmission Unit 403 Receiving Unit 404 Signature Verification Unit 405 Validity Check Unit 406 Installation Detection Unit 407 First Installation Unit 408 Second Installation Unit 501 receiving unit 502 Generator Units 503 Transmitting Unit 504 Signature Unit 505 Installation Detection Unit 60 devices 601 processor 602 memory 603 Communication Interface

Claims

1. 1. A method for acquiring a file based on wireless OTA technology, the method comprising: acquiring, by a first vehicle, a target request, the target request including target service information, the target service information being used to acquire a target file associated with a target function; sending, by the first vehicle, the target request to a server; receiving, by the first vehicle, the target file requested by the target request, the target file being used to indicate to the first vehicle that the target function is to be implemented; A method comprising:

2. The method comprises: performing, by the first vehicle, a signature verification on the target file; if the signature verification of the target file is successful, implementing the target function by the first vehicle based on the target file; 10. The method of claim 1, further comprising:

3. The method comprises: checking, by the first vehicle, the validity of the target file; if the validity check of the target file is successful, implementing, by the first vehicle, the target function based on the target file; 3. The method of claim 1 or 2, further comprising:

4. The target request further includes hardware information of the first vehicle, and the target file includes a device feature code generated based on the hardware information, and the step of checking the validity of the target file by the first vehicle includes: determining, by the first vehicle, whether the hardware information matches the device feature code; and determining, if the hardware information matches the device feature code, that the target file is a valid file.

4. The method of claim 3, comprising:

5. The method comprises: detecting, by the first vehicle, whether software corresponding to the target function is installed in the first vehicle based on the target service information and at least one software version information corresponding to the first vehicle; 5. The method of claim 1, further comprising:

6. The method comprises: If the software corresponding to the target function is not installed in the first vehicle, sending, by the first vehicle, an installation package acquisition request for the software corresponding to the target function to the server.

6. The method of claim 5, further comprising:

7. The method comprises: receiving, by the first vehicle, the installation package sent by the server based on the installation package acquisition request, and performing signature verification on the installation package; If the signature verification of the installation package is successful, installing the software corresponding to the target function in the first vehicle based on the installation package, and implementing the target function based on the software and the target file; 7. The method of claim 6, further comprising:

8. The target request further includes at least one software version information corresponding to the first vehicle, and the method further comprises: receiving, by the first vehicle, an installation package of the software corresponding to the target function sent by the server, and performing signature verification on the installation package, the installation package being sent by the server when the server detects, based on the target service information and the software version information, that the software corresponding to the target function is not installed in the first vehicle; If the signature verification of the installation package is successful, installing the software corresponding to the target function in the first vehicle based on the installation package, and implementing the target function based on the software and the target file; 5. The method of claim 1, further comprising:

9. the first vehicle includes a master vehicle control unit and one or more slave vehicle control units, the target function is a function implemented by a target slave vehicle control unit of the one or more slave vehicle control units, and the step of receiving, by the first vehicle, the target file requested by the target request includes: receiving, by the master vehicle control unit, the target file requested by the target request; transmitting, by the master vehicle control unit, the target file to the target slave vehicle control unit, the target file being used to indicate to the target slave vehicle control unit which target function to implement based on the target file; 9. The method of any one of claims 1 to 8, comprising:

10. The first vehicle further includes a human-machine interface, and the step of acquiring a target request by the first vehicle includes: obtaining, by the first vehicle, the target request via the human-machine interface; 10. The method of any one of claims 1 to 9, comprising:

11. The method comprises: transmitting, by the first vehicle, a state of the target feature to the server, the state of the target feature including whether the target feature is implemented and / or a validity period of the target feature; 11. The method of any one of claims 1 to 10, further comprising:

12. 12. The method of claim 1, wherein the target request further includes one or more of the validity period of the target function, the hardware information of the first vehicle, and the at least one software version information corresponding to the first vehicle, and the target file is generated by the server based on one or more of the target service information, the validity period of the target function, the hardware information, and the at least one software version information.

13. The method of claim 1 , wherein the target file includes a usage license file for the target function.

14. 1. A method for acquiring a file based on wireless OTA technology, the method comprising: receiving, by a server, a target request transmitted by a first vehicle, the target request including target service information, the target service information being used to obtain a target file associated with a target function; generating, by the server, the corresponding target file based on the target request; transmitting, by the server, the target file to the first vehicle, the target file being used to indicate to the first vehicle that the target function is to be implemented; A method comprising:

15. The method comprises: signing the target file by the server; 15. The method of claim 14, further comprising:

16. The target request further includes at least one software version information corresponding to the first vehicle, and the method further comprises: detecting, by the server, whether software corresponding to the target function is installed in the first vehicle based on the at least one software version information and the target service information; If the software corresponding to the target function is not installed in the first vehicle, sending, by the server, an installation package of the software corresponding to the target function to the first vehicle, the installation package being used to install the software corresponding to the target function in the first vehicle based on the installation package; 16. The method of claim 14 or 15, further comprising:

17. 17. The method of claim 14, wherein the target request further includes one or more of: a validity period of the target feature, hardware information of the first vehicle, and the at least one software version information corresponding to the first vehicle.

18. generating, by the server, the corresponding target file based on the target request; generating, by the server, a device feature code based on the hardware information of the first vehicle; generating, by the server, resource control items and function control items based on the at least one software version information corresponding to the first vehicle; generating, by the server, the target file based on the target service information, the validity period of the target function, the device feature code, the resource control item, and the function control item; 18. The method of claim 17, comprising:

19. The method comprises: receiving, by the server, a status of the target function transmitted by the first vehicle, the status of the target function including whether the target function is enabled and / or the validity period of the target function; 19. The method of any one of claims 14 to 18, further comprising:

20. The method of claim 14 , wherein the target file includes a usage license file for the target function.

21. an acquisition unit configured to acquire a target request, the target request including target service information, the target service information being used to acquire a target file associated with a target function; a sending unit configured to send the target request; a receiving unit configured to receive the target file requested by the target request, the target file being used to indicate the vehicle that implements the target function; A vehicle equipped with:

22. The vehicle, a signature verification unit configured to perform signature verification of the target file, wherein the vehicle implements the target function based on the target file if the signature verification of the target file is successful; 22. The vehicle of claim 21 further comprising:

23. The vehicle, a validity check unit configured to check the validity of the target file, wherein the vehicle implements the target function based on the target file if the validity check of the target file is successful; 23. The vehicle of claim 21 or 22, further comprising:

24. 24. The vehicle of claim 23, wherein the target request further comprises hardware information of the vehicle, and the target file includes a device feature code generated based on the hardware information, and the validity check unit is specifically configured to determine whether the hardware information matches the device feature code, and if the hardware information matches the device feature code, determine that the target file is a valid file.

25. The vehicle, an installation detection unit configured to detect whether software corresponding to the target function is installed in the vehicle based on the target service information and at least one software version information corresponding to the vehicle; 25. A vehicle according to any one of claims 21 to 24, further comprising:

26. 26. The vehicle of claim 25, wherein the sending unit is further configured to send to the server an installation package acquisition request for the software corresponding to the target function if the software corresponding to the target function is not installed in the vehicle.

27. The vehicle, a first installation unit configured to receive an installation package sent by the server based on the installation package acquisition request, perform signature verification on the installation package, and if the signature verification of the installation package is successful, install the software corresponding to the target function based on the installation package, and implement the target function based on the software and the target file; 27. The vehicle of claim 26, further comprising:

28. The target request further includes at least one software version information corresponding to the vehicle, and the vehicle: a second installation unit configured to receive an installation package of software corresponding to the target function sent by the server, perform signature verification on the installation package, the installation package being sent by the server when the server detects that the software corresponding to the target function is not installed in the vehicle based on the target service information and the software version information, and install the software corresponding to the target function based on the installation package if signature verification of the installation package is successful, and implement the target function based on the software and the target file.

25. A vehicle according to any one of claims 21 to 24, further comprising:

29. the vehicle comprises a master vehicle control unit and one or more slave vehicle control units, the target function is a function implemented by a target slave vehicle control unit of the one or more slave vehicle control units, and the receiving unit receiving, via the master vehicle control unit, the target file requested by the target request; and transmitting, via the master vehicle control unit, the target file to the target slave vehicle control unit, the target file being used to indicate to the target slave vehicle control unit which target function to implement based on the target file; 29. A vehicle according to any one of claims 21 to 28, specifically adapted to:

30. 30. The vehicle of claim 21, wherein the target request further includes one or more of the validity period of the target function, the hardware information of the vehicle, and the at least one software version information corresponding to the vehicle, and the target file is generated by the server based on one or more of the target service information, the validity period of the target function, the hardware information, and the at least one software version information.

31. a receiving unit configured to receive a target request transmitted by a first vehicle, the target request including target service information, the target service information being used to obtain a target file associated with a target function; a generating unit configured to generate the corresponding target file based on the target request; a sending unit configured to send the target file to the first vehicle, the target file being used to indicate to the first vehicle that the target function is to be implemented; and A server comprising:

32. The server: a signing unit configured to sign the target file; 32. The server of claim 31, further comprising:

33. The target request further includes at least one software version information corresponding to the first vehicle, and the server: an installation detection unit configured to detect whether software corresponding to the target function is installed in the first vehicle based on the at least one software version information and the target service information. Furthermore, the sending unit is further configured to, if the software corresponding to the target function is not installed in the first vehicle, send an installation package of the software corresponding to the target function to the first vehicle, and the installation package is used to install the software corresponding to the target function in the first vehicle based on the installation package; 33. A server according to claim 31 or 32.

34. 34. The server of claim 31, wherein the target request further includes one or more of: a validity period of the target feature, hardware information of the first vehicle, and the at least one software version information corresponding to the first vehicle.

35. The generating unit: generating a device feature code based on the hardware information of the first vehicle; Generate resource control items and function control items based on the at least one software version information corresponding to the first vehicle; generating the target file based on the target service information, the validity period of the target function, the device feature code, the resource control item, and the function control item; 35. The server of claim 34, specifically configured to:

36. A system for acquiring a file based on wireless OTA technology, the system comprising: a server and a vehicle; The server is a server according to any one of claims 31 to 34, The vehicle is a vehicle according to any one of claims 21 to 30. system.

37. A chip system comprising at least one processor, a memory, and an interface circuit, the memory, the interface circuit, and the at least one processor being connected by lines, the at least one memory storing instructions that, when executed by the processor, implement the method of any one of claims 1 to 13 or any one of claims 14 to 20.

38. 21. A computer storage medium storing a computer program that, when executed on one or more processors, implements the method of any one of claims 1 to 13 or any one of claims 14 to 20.

39. 21. A computer program comprising instructions which, when executed by a computer, cause the computer to perform the method of any one of claims 1 to 13 or the method of any one of claims 14 to 20.

Images