Function design method, device and equipment of OTA client and medium

Abstract

The invention provides a function design method and device for an OTA client, equipment and a medium. The function design method for the OTA client comprises the steps that a configuration file is acquired; determining a function identifier of a target function from the configuration file; initializing a target function node matched with the function identifier in a function node pool; wherein the target function node is a program module used for realizing a target function, and the target function is a function related to OTA upgrade. Through the technical scheme of the invention, flexible customization of the OTA client service function can be realized, repeated development of the same service function is avoided, and the development cost is reduced.

Description

Technical Field

[0001] The present application relates to the field of OTA upgrade technology, and in particular to a functional design method, apparatus, device, and medium for an OTA client. Background Art

[0002] Over-the-Air Technology (OTA) is a technology that enables device software or firmware upgrades via wireless communication. OTA upgrades are convenient and efficient, and can be completed over Wi-Fi or mobile networks, effectively over-the-air. During an OTA upgrade, users don't need to connect their device to a computer or perform complex operations; they simply need to ensure the device is connected to a stable network. This greatly simplifies the upgrade process, reduces operational complexity, and reduces the risk of device damage caused by flashing the device.

[0003] The OTA system consists of an OTA master node and an OTA client. For cars, the OTA master node is typically deployed on a central node gateway and is primarily responsible for checking the vehicle's installation conditions, maintaining the installation status, and controlling the installation process according to the upgrade policy. The OTA client, typically deployed on a vehicle computer, T-BOX, or smart terminal device such as a mobile phone, serves as the entry point for user interaction and is responsible for downloading upgrade packages. Some OTA clients also handle operations such as decompression, decryption, and verification of the upgrade packages.

[0004] OTA clients developed by different manufacturers are responsible for different business functions (such as downloading upgrade packages, decompressing upgrade packages, and verifying upgrade packages), as well as the algorithms (such as decompression algorithms, decryption algorithms, verification algorithms, etc.) and protocols (such as file download protocols, communication protocols, etc.) used to implement these business functions. Even the same manufacturer's OTA clients for different projects have different business function implementation processes. Therefore, current OTA clients are basically highly customized and difficult to unify. Switching a project or making slight changes to the business process requires in-depth modifications or even the re-development of a new OTA client solution.

[0005] In view of this, this application is hereby filed. Summary of the Invention

[0006] The present application aims to provide a functional design method, apparatus, device and medium for an OTA client, which can realize flexible customization of the business functions of the OTA client, avoid repeated development of the same business functions, and reduce development costs.

[0007] In a first aspect, an embodiment of the present application provides a functional design method for an OTA client, including:

[0008] Get the configuration file;

[0009] determining a function identifier of a target function from the configuration file;

[0010] Initializing a target function node in a function node pool that matches the function identifier;

[0011] The target function node is a program module for implementing a target function, and the target function is a function related to OTA upgrade.

[0012] According to the technical solution provided in the embodiment of the present application, optionally, there are multiple target functions, and while determining the function identifier of the target function from the configuration file, the method further includes:

[0013] The execution sequence identifiers of the target functions are determined respectively from the configuration files.

[0014] According to the technical solution provided in the embodiment of the present application, optionally, after initializing the target function node in the function node pool that matches the function identifier, the method further includes:

[0015] In response to receiving the upgrade start instruction, the corresponding target function nodes are controlled to run in sequence according to the execution sequence identifier, and the output information of the adjacent previous target function node is used as the input information of the next target function node.

[0016] According to the technical solution provided in the embodiment of the present application, optionally, while determining the function identifier of the target function from the configuration file, the method further includes:

[0017] Determining an associated protocol identifier and / or an associated algorithm identifier of a target function from the configuration file;

[0018] The associated protocol identifier indicates the protocol used when the target function is implemented, and the associated algorithm identifier indicates the algorithm used when the target function is implemented.

[0019] According to the technical solution provided in the embodiment of the present application, optionally, initializing the target function node in the function node pool that matches the function identifier includes:

[0020] Setting protocol parameters of the target functional node according to the associated protocol identifier;

[0021] And / or, setting the protocol parameters of the target functional node according to the association algorithm identifier.

[0022] According to the technical solution provided in the embodiment of the present application, optionally, determining the function identifier of the target function from the configuration file includes:

[0023] The data corresponding to the preset field in the configuration file is determined as the function identifier of the target function.

[0024] According to the technical solution provided in the embodiment of the present application, optionally, the target functions include: OTA upgrade package download, OTA upgrade package integrity verification, OTA upgrade package decryption, OTA upgrade package signature verification, OTA upgrade package decompression or OTA upgrade package installation.

[0025] In a second aspect, an embodiment of the present application further provides a function design device for an OTA client, comprising: an acquisition module for acquiring a configuration file;

[0026] a determination module, configured to determine a function identifier of a target function from the configuration file;

[0027] An initialization module, configured to initialize a target function node in a function node pool that matches the function identifier;

[0028] The target function node is a program module for implementing a target function, and the target function is a function related to OTA upgrade.

[0029] In a third aspect, an embodiment of the present application further provides an electronic device, comprising:

[0030] processor and memory;

[0031] The processor is configured to execute the steps of the functional design method of the OTA client as described in any embodiment by calling the program or instructions stored in the memory.

[0032] In a fourth aspect, an embodiment of the present application further provides a computer-readable storage medium, wherein the computer-readable storage medium stores a program or instruction, and the program or instruction enables a computer to execute the steps of the functional design method of the OTA client as described in any embodiment.

[0033] In summary, this application proposes a functional design method for an OTA client, which is essentially a set of OTA client implementation solutions that support full functions. Specifically, the business functions that the OTA client may involve are stored in the form of independent target function nodes in a function node pool. Each target function node supports common technical protocols and algorithms. The demander can determine the target function undertaken by the OTA client in the form of a configuration file based on its own personalized needs, thereby achieving flexible customization of the OTA client's business functions, avoiding repeated development of the same business function, and reducing development costs. Specifically, the following technical means are included: obtaining a configuration file; determining the function identifier of the target function from the configuration file; initializing the target function node in the function node pool that matches the function identifier; wherein the target function node is a program module for implementing the target function, and the target function is a function related to OTA upgrades. BRIEF DESCRIPTION OF THE DRAWINGS

[0034] Figure 1 This is a structural diagram of an OTA system provided in an embodiment of the present application;

[0035] Figure 2 This is a process of a functional design method of an OTA client provided in an embodiment of the present application Figure 1 ;

[0036] Figure 3 This is a schematic diagram of a functional node pool provided in an embodiment of the present application;

[0037] Figure 4 This is a process of a functional design method of an OTA client provided in an embodiment of the present application Figure 2 ;

[0038] Figure 5 This is a process of a functional design method of an OTA client provided in an embodiment of the present application Figure 3 ;

[0039] Figure 6 This is a schematic diagram of the structure of an OTA client provided in an embodiment of the present application;

[0040] Figure 7 This is a process of a functional design method of an OTA client provided in an embodiment of the present application Figure 4 ;

[0041] Figure 8 This is a structural diagram of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0042] The present application will be further described in detail below with reference to the accompanying drawings and examples. It should be understood that the specific embodiments described herein are merely for the purpose of explaining the relevant invention and are not intended to limit the invention. It should also be noted that, for ease of description, only portions relevant to the invention are shown in the accompanying drawings.

[0043] It should be noted that, in the absence of conflict, the embodiments and features of the embodiments in this application can be combined with each other. The present application will be described in detail below with reference to the accompanying drawings and in combination with the embodiments.

[0044] As described in the background, OTA (Over-the-Air Technology) is a technology that enables device software or firmware upgrades via wireless communication, also known as OTA upgrades. OTA upgrades are convenient and efficient, and can be completed using Wi-Fi or mobile networks, which is equivalent to completing upgrades over the air. During the OTA upgrade process, users do not need to connect their devices to a computer or perform complex operations; they only need to ensure that the device is connected to a stable network. This greatly simplifies the upgrade process, reduces the user's operational difficulty, and also reduces the risk of device damage caused by flashing the upgrade.

[0045] like Figure 1 As shown, the OTA system includes an OTA master node 110, an OTA client 120, and a cloud 130. For a car, the OTA master node 110 is usually deployed on a central node gateway. It is mainly responsible for obtaining upgrade task information from the cloud 130, feeding back the upgrade status to the cloud 130, checking the installation conditions of the entire vehicle, maintaining the installation status, and controlling the installation process according to the upgrade strategy. The OTA client 120 is usually deployed on a smart terminal device such as a car computer, T-BOX, or a mobile phone. It is the entrance for interacting with the user. It is also responsible for receiving the start upgrade instruction issued by the OTA master node 110, feeding back the upgrade status to the OTA master node 110, downloading the upgrade package from the cloud 130, and some OTA clients 120 are also responsible for decompressing, decrypting, verifying, and other operations on the upgrade package. The cloud 130 is responsible for the management of the upgrade package, the management of the upgrade task, and the push of the upgrade package.

[0046] OTA clients developed by different manufacturers are responsible for different business functions (such as downloading upgrade packages, decompressing upgrade packages, and verifying upgrade packages), as well as the algorithms (such as decompression algorithms, decryption algorithms, verification algorithms, etc.) and protocols (such as file download protocols, communication protocols, etc.) used to implement these business functions. Even the same manufacturer's OTA clients for different projects have different business function implementation processes. Therefore, current OTA clients are basically highly customized and difficult to unify. Switching a project or making slight changes to the business process requires in-depth modifications or even the re-development of a new OTA client solution.

[0047] Automobiles mainly include several subsystems such as infotainment systems, in-vehicle communication systems, driver assistance systems, and vehicle control systems. The current automotive OTA solution is mainly aimed at processing the entire vehicle upgrade solution, focusing on completing the upgrade process of each OTA subsystem, including the interaction between each module and with the cloud. Among them, the OTA client also has many businesses to handle, such as file download, signature verification, integrity verification, decompression, decryption, system flashing and other operations. The processing operations that the OTA client is responsible for are different for each manufacturer's requirements and specific implementation plans, and even the processing processes for different projects of the same manufacturer are different. Therefore, the current OTA clients are basically highly customized. Switching a project or slightly modifying the business process requires in-depth modification or even redevelopment of a new OTA client solution.

[0048] In other words, OTA clients from different manufacturers perform inconsistent functions within vehicle upgrade solutions. The same functions often utilize different algorithms and support different protocols, resulting in highly customized OTA clients and making standardization difficult. For example, manufacturer A's OTA client only features download and integrity verification, while manufacturer B's OTA client includes download, integrity verification, decryption, and signature verification. Manufacturer A's OTA client uses the SHA-128 algorithm for integrity verification, while manufacturer B's uses the SHA-256 algorithm. These diverse OTA client functions and the specific algorithms and protocols used to implement them necessitate a high degree of customization, leading to extensive duplication of development during project implementation. This duplication is not only inefficient but also significantly wastes valuable human and material resources, increasing overall project costs and development cycles.

[0049] In response to the problems existing in the current automotive OTA solutions, by summarizing the common functions of the infotainment system OTA client in existing projects, this application proposes a platform-based processing solution suitable for the infotainment system OTA client.

[0050] Figure 2 This is a flow chart of a method for designing the functionality of an OTA client provided in an embodiment of the present application. The method for designing the functionality of an OTA client can be executed by a device for designing the functionality of an OTA client, which can be implemented in software and / or hardware and integrated into a vehicle computer.

[0051] See also Figure 2 The functional design method of the OTA client specifically includes the following steps:

[0052] S210: Obtain a configuration file.

[0053] Among them, users (also known as demanders) determine the target functions of the OTA client in the form of configuration files based on their own personalized needs. In this way, the different needs of different users can be met, and users can customize the functions of the OTA client, realizing flexible customization of the OTA client functions.

[0054] For example, some users' projects only require two business functions: downloading and integrity verification, while others require three business functions: downloading, integrity verification, and decompression. To meet the different needs of different users for the OTA client, users can configure the business functions they need in the configuration file.

[0055] The configuration file may be stored in a preset location, ie, the configuration file may be obtained from the preset location.

[0056] S220: Determine a function identifier of a target function from the configuration file.

[0057] By parsing the configuration file, the function identifier of the target function is determined.

[0058] Exemplarily, the data corresponding to a preset field in the configuration file is determined as the function identifier of the target function. The preset field may be, for example, "name" or "type." The function identifier of the target function may be "download," indicating a download function; "decryption," indicating a decryption function; or "integrity," indicating an integrity check function.

[0059] It is understandable that the function identifier of the target function may also be "1" for downloading function, "2" for decryption function, or "3" for integrity verification function, etc. In short, the function identifier of the target function is used to mark the corresponding business function.

[0060] Based on the actual project situation, this application summarizes and refines the main business functions of the OTA client, including: OTA upgrade package download, OTA upgrade package integrity verification, OTA upgrade package decryption, OTA upgrade package signature verification, OTA upgrade package decompression and OTA upgrade package installation.

[0061] OTA upgrade package download refers to downloading the upgrade package from the cloud to your local device. OTA upgrade package integrity verification refers to performing an integrity check on the OTA upgrade package downloaded from the cloud to prevent data loss during the download process. OTA upgrade package decryption refers to decrypting the downloaded OTA upgrade package. OTA upgrade package signature verification refers to verifying the signature of the upgrade file to ensure it has not been tampered with. OTA upgrade package decompression refers to extracting the upgrade file from the downloaded compressed package. OTA upgrade package installation refers to using the upgrade file to upgrade the system.

[0062] S230: Initialize the target function node in the function node pool that matches the function identifier.

[0063] The target function node is a program module used to implement the target function, which is related to OTA upgrades. Target functions include, for example, OTA upgrade package download, OTA upgrade package integrity check, OTA upgrade package decryption, OTA upgrade package signature verification, OTA upgrade package decompression, and OTA upgrade package installation.

[0064] The function node pool stores multiple function nodes for implementing different business functions. After users express their needs through configuration files, the corresponding function nodes in the function node pool are initialized based on the target functions configured in the configuration files, thus implementing their specific functions. By setting up corresponding function nodes for different business functions, we can achieve user customization while enabling the reuse of function nodes, avoiding the problem of duplicate development of the same function node and saving costs.

[0065] like Figure 3 As shown in the figure, the function node pool includes download nodes, integrity verification nodes, decryption nodes, signature verification nodes, decompression nodes, and installation nodes. Different nodes represent program modules used to implement different business functions. For example, by parsing the configuration file and determining that the function identifier of the target function is "download", the download node in the function node pool is initialized and put into working state. In this way, the OTA client has the upgrade package download function. When the upgrade start instruction is received, the download node starts running and downloads the upgrade package from the specified location.

[0066] For another example, by parsing the configuration file and determining that the function identifiers of the target function are "download" and "integrity," the download node and integrity check node in the function node pool are initialized and put into operation. In this way, the OTA client has the function of downloading the upgrade package and performing integrity verification on the downloaded upgrade package. When the start upgrade instruction is received, the download node is controlled to start running, downloading the upgrade package from the specified location, and then transmitting the downloaded upgrade package to the integrity verification node, which is controlled to run and perform integrity verification on the downloaded upgrade package.

[0067] The functional design method of the OTA client provided in the embodiment of the present application is essentially a set of OTA client implementation solutions that support full functions. Specifically, the business functions that may be involved in the OTA client are stored in the form of independent target function nodes in a function node pool. Each target function node supports common technical protocols and algorithms. The demander can determine the target functions undertaken by the OTA client in the form of a configuration file based on its own personalized needs, thereby realizing flexible customization of the OTA client's business functions, avoiding repeated development of the same business functions, and reducing development costs.

[0068] On the basis of the above embodiments, the execution order between different target functions can be further configured. For example, some projects require the integrity of the upgrade package to be verified after the upgrade package is downloaded, while some projects require the upgrade package to be decrypted first and then the integrity of the upgrade package is verified. In other words, the execution order of different target functions required by different projects is different. Therefore, in the present application scheme, not only the target functions required can be configured through the configuration file, but also the execution order between different target functions can be configured, thus achieving more fine-grained customization. Specifically, as Figure 4 As shown, the following steps are included:

[0069] S410: Obtain a configuration file.

[0070] S420: Determine function identifiers of target functions and execution sequence identifiers of the target functions from the configuration file.

[0071] S430: Initialize the target function node in the function node pool that matches the function identifier.

[0072] S440 : In response to receiving the upgrade start instruction, control the corresponding target function nodes to run in sequence according to the execution sequence identifier, and use the output information of the adjacent previous target function node as the input information of the next target function node.

[0073] For example, the target functions are determined from the configuration file as download, integrity verification, and decryption. The execution order is to execute the download node first, then the decryption node, and finally the integrity verification node. When the upgrade start instruction is received, the download node, decryption node, and integrity verification node are controlled to run in sequence. The upgrade package downloaded by the download node is sent to the decryption node. The decryption node decrypts the upgrade package, obtaining the decrypted upgrade package, which is then sent to the integrity verification node.

[0074] On the basis of the above embodiments, the protocols or algorithms applied when implementing different target functions can be further configured. For example, some user projects require the use of the file download protocol HTTPS when downloading the upgrade package from the cloud, while some user projects require the use of the file download protocol HTTP when downloading the upgrade package from the cloud, and some user projects require the use of the SSL / TLS protocol. For example, some user projects require the use of the MD5 algorithm when performing integrity verification on the upgrade package, while some user projects require the use of the SHA1 algorithm, etc. That is, different user projects require different protocols or algorithms for the application of target functions. In order to meet the user's more fine-grained customization needs, the solution proposed in the embodiment of the present application supports users to customize the protocols and algorithms for the application of target functions. Specifically, such as Figure 5 As shown, the following steps are included:

[0075] S510: Obtain a configuration file.

[0076] S520: Determine a function identifier of a target function, an associated protocol identifier of the target function, and / or an associated algorithm identifier from the configuration file.

[0077] The associated protocol identifier indicates the protocol used when the target function is implemented, and the associated algorithm identifier indicates the algorithm used when the target function is implemented.

[0078] For example, the download function supports protocols such as HTTPS, HTTP, and SSL / TLS. The integrity check function supports hash algorithms such as MD5, SHA1, SHA128, SHA256, SHA512, and HMAC. The decryption function supports symmetric encryption and decryption algorithms such as AES, DES, 3DES, and RC4. The decompression function supports algorithms such as ZIP, RAR, and 7Z. The signature verification function supports asymmetric signature algorithms such as RSA, ECC, DSA, and ECDSA. The installation function supports Android update_engine. The communication protocols supported by various functions include IPCP, GRPC, SomeIP, and Binder.

[0079] S530: Initialize the target function node in the function node pool that matches the function identifier.

[0080] Specifically, the protocol parameters of the target functional node are set according to the associated protocol identifier; and / or the protocol parameters of the target functional node are set according to the associated algorithm identifier. In this way, when the target functional node is running, the matching protocol or algorithm is called according to the set parameter values ​​to implement the service function.

[0081] Based on the same inventive concept, corresponding to any of the above-mentioned embodiment methods, the present application also provides a function design device for an OTA client, including: an acquisition module for acquiring a configuration file; a determination module for determining a function identifier of a target function from the configuration file; an initialization module for initializing a target function node in a function node pool that matches the function identifier; wherein the target function node is a program module for implementing a target function, and the target function is a function related to OTA upgrade.

[0082] Based on the above embodiments, Figure 6 A schematic diagram of the structure of an OTA client is shown, including a configuration module 610, which is used by users to configure the function identifier, execution sequence identifier, and application protocol and / or algorithm identifier of their desired target function in a configuration file; a configuration parsing module 620, which is used to parse the configuration file to determine the function identifier, execution sequence identifier, application protocol and / or algorithm identifier, etc. A communication module 630 is used for communicating with the cloud or OTA master node, or between different target functions. A function node pool 640 is used to store multiple target function nodes.

[0083] Correspondingly, refer to Figure 7 The design process of an OTA client shown in the figure includes the following steps:

[0084] S710: Configure the target functional nodes of the OTA client, the execution order between different nodes, and related protocols and algorithms according to project requirements.

[0085] S720: Parse the configuration file, initialize the configured target functional nodes and the protocols and algorithms applied by the target functional nodes.

[0086] S730: Receive an upgrade start instruction.

[0087] S740 , controlling the target functional nodes to run sequentially according to the execution order between different nodes.

[0088] S750: Report the upgrade status.

[0089] For the convenience of description, the above devices are described as being divided into various modules according to their functions. Of course, when implementing this application, the functions of each module can be implemented in the same or multiple software and / or hardware.

[0090] The apparatus of the above embodiment is used to implement the functional design method of the corresponding OTA client in any of the above embodiments, and has the beneficial effects of the corresponding method embodiment, which will not be repeated here.

[0091] For the convenience of description, the above devices are described as being divided into various modules according to their functions. Of course, when implementing this application, the functions of each module can be implemented in the same or multiple software and / or hardware.

[0092] The device of the above embodiment is used to implement the corresponding driving behavior evaluation method in any of the above embodiments, and has the beneficial effects of the corresponding method embodiment, which will not be repeated here.

[0093] Figure 8 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present application. Figure 8 As shown, the electronic device 500 includes one or more processors 501 and a memory 502 .

[0094] The processor 501 may be a central processing unit (CPU) or other forms of processing units having data processing capabilities and / or instruction execution capabilities, and may control other components in the electronic device 500 to perform desired functions.

[0095] The memory 502 may include one or more computer program products, which may include various forms of computer-readable storage media, such as volatile memory and / or non-volatile memory. The volatile memory may, for example, include random access memory (RAM) and / or cache memory (cache), etc. The non-volatile memory may, for example, include read-only memory (ROM), a hard disk, a flash memory, etc. One or more computer program instructions may be stored on the computer-readable storage medium, and the processor 501 may run the program instructions to implement the functional design method of the OTA client of any embodiment of the present application described above and / or other desired functions. Various contents such as initial external parameters, thresholds, etc. may also be stored in the computer-readable storage medium.

[0096] In one example, the electronic device 500 may further include an input device 503 and an output device 504, which are interconnected via a bus system and / or other connection mechanisms (not shown). The input device 503 may include, for example, a keyboard, a mouse, etc. The output device 504 may output various information to the outside, including warning information, braking force, etc. The output device 504 may include, for example, a display, a speaker, a printer, a communication network, and remote output devices connected thereto.

[0097] Of course, to simplify, Figure 8 Only some of the components related to the present application in the electronic device 500 are shown, and components such as buses, input / output interfaces, etc. are omitted. In addition, the electronic device 500 may further include any other appropriate components according to specific application scenarios.

[0098] In addition to the above-mentioned methods and devices, an embodiment of the present application may also be a computer program product, which includes computer program instructions, which, when executed by a processor, enable the processor to execute the steps of the functional design method of the OTA client provided in any embodiment of the present application.

[0099] The computer program product may be written in any combination of one or more programming languages ​​to implement the program code for performing the operations of the embodiments of the present application, including object-oriented programming languages ​​such as Java, C++, and conventional procedural programming languages ​​such as "C" or similar programming languages. The program code may be executed entirely on the user's computing device, partially on the user's computing device, as a standalone software package, partially on the user's computing device and partially on a remote computing device, or entirely on a remote computing device or server.

[0100] In addition, an embodiment of the present application may also be a computer-readable storage medium having computer program instructions stored thereon, which, when executed by a processor, causes the processor to execute the steps of the functional design method of the OTA client provided in any embodiment of the present application.

[0101] The computer-readable storage medium can adopt any combination of one or more readable media. The readable medium can be a readable signal medium or a readable storage medium. The readable storage medium can, for example, include but is not limited to a system, device or component of electricity, magnetism, light, electromagnetic, infrared, or semiconductor, or any combination thereof. More specific examples (non-exhaustive list) of readable storage media include: an electrical connection with one or more wires, a portable disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination thereof.

[0102] It should be noted that the terms used in this application are only for describing specific embodiments and are not intended to limit the scope of this application. As shown in the specification and claims of this application, unless the context clearly indicates an exception, the words "one", "an", "a kind of" and / or "the" do not specifically refer to the singular and may also include the plural. The terms "comprise", "include" or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method or device comprising a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method or device. In the absence of further restrictions, the elements defined by the sentence "comprise a..." do not exclude the presence of other identical elements in the process, method or device comprising the elements.

[0103] It should also be noted that the terms "center", "up", "down", "left", "right", "vertical", "horizontal", "inside", "outside", etc., indicating orientations or positional relationships, are based on the orientations or positional relationships shown in the accompanying drawings, and are only for the convenience of describing this application and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, be constructed and operated in a specific orientation, and therefore cannot be understood as a limitation on this application. Unless otherwise clearly specified and limited, the terms "installed", "connected", "connected", etc. should be understood in a broad sense, for example, it can be a fixed connection, a detachable connection, or an integral connection; it can be a mechanical connection or an electrical connection; it can be a direct connection, or an indirect connection through an intermediate medium, or it can be a communication between the internal parts of two elements. For those of ordinary skill in the art, the specific meanings of the above terms in this application can be understood according to specific circumstances.

[0104] This article uses specific examples to illustrate the principles and implementation methods of this application. The description of the above embodiments is only used to help understand the method and core ideas of this application. The above is only the preferred implementation method of this application. It should be pointed out that due to the limitations of textual expression, there are objectively infinite specific structures. For ordinary technicians in this technical field, without departing from the principles of the present invention, they can also make several improvements, modifications or changes, and can also combine the above technical features in an appropriate manner; these improvements, modifications, changes or combinations, or the direct application of the inventive concept and technical solution to other occasions without improvement, should be regarded as the scope of protection of this application.

Claims

1. A functional design method for an OTA client, characterized in that: include: Get the configuration file; determining a function identifier of a target function from the configuration file; Initializing a target function node in a function node pool that matches the function identifier; The target function node is a program module for implementing a target function, and the target function is a function related to OTA upgrade.

2. The method according to claim 1, characterized in that There are multiple target functions. When determining the function identifier of the target function from the configuration file, the method further includes: The execution sequence identifiers of the target functions are determined respectively from the configuration files.

3. The method according to claim 2, characterized in that After initializing the target function node in the function node pool that matches the function identifier, the method further includes: In response to receiving the upgrade start instruction, the corresponding target function nodes are controlled to run in sequence according to the execution sequence identifier, and the output information of the adjacent previous target function node is used as the input information of the next target function node.

4. The method according to claim 1, wherein The step of determining the function identifier of the target function from the configuration file also includes: Determining an associated protocol identifier and / or an associated algorithm identifier of a target function from the configuration file; The associated protocol identifier indicates the protocol used when the target function is implemented, and the associated algorithm identifier indicates the algorithm used when the target function is implemented.

5. The method according to claim 4, characterized in that Initializing the target function node in the function node pool that matches the function identifier includes: Setting protocol parameters of the target functional node according to the associated protocol identifier; And / or, setting the protocol parameters of the target functional node according to the association algorithm identifier.

6. The method according to claim 1, characterized in that Determining the function identifier of the target function from the configuration file includes: The data corresponding to the preset field in the configuration file is determined as the function identifier of the target function.

7. The method according to claim 1, characterized in that The target functions include: OTA upgrade package download, OTA upgrade package integrity check, OTA upgrade package decryption, OTA upgrade package signature verification, OTA upgrade package decompression or OTA upgrade package installation.

8. A functional design device for an OTA client, characterized in that: include: Get module, used to get configuration files; a determination module, configured to determine a function identifier of a target function from the configuration file; An initialization module, configured to initialize a target function node in a function node pool that matches the function identifier; The target function node is a program module for implementing a target function, and the target function is a function related to OTA upgrade.

9. An electronic device, characterized in that: The electronic device comprises: processor and memory; The processor is configured to execute the steps of the functional design method of the OTA client according to any one of claims 1 to 7 by calling the program or instructions stored in the memory.

10. A computer-readable storage medium, characterized in that The computer-readable storage medium stores a program or instruction, which enables a computer to execute the steps of the function design method of the OTA client according to any one of claims 1 to 7.

Images