Verification methods, devices, servers, storage media, and products for OTA upgrade operations.

Abstract

The application relates to the technical field of Internet of Vehicles, in particular to a verification method and device of an OTA upgrade operation, a server, a storage medium and a product, wherein the method comprises the following steps: when detecting an upgrade instruction of a vehicle, the mailbox type of a user is acquired; if the mailbox type is a first type, a security check code is generated based on a token bucket, and if the mailbox type is a second type, the security check code is generated based on the value of a current window counter; and the OTA upgrade operation is verified according to the security check code. Therefore, the problems that the related art cannot meet the upgrade requirements in different scenarios and has poor security are solved.

Description

Technical Field

[0001] This application relates to the field of vehicle networking technology, and in particular to a verification method, device, server, storage medium and product for OTA upgrade operations. Background Technology

[0002] With the continuous development of technology, the automotive industry is also gradually introducing OTA (Over-The-Air) technology, which is bringing a series of new functions and conveniences to traditional cars.

[0003] In related technologies, when operating OTA upgrade-related functions on the OTA platform, it is only necessary to upload or distribute OTA upgrade packages through a web page, which poses certain security risks. Moreover, for users who frequently need to perform OTA upgrades, they may need to upgrade many vehicles in a short period of time, or there may be multiple upgrade tasks. Alternatively, when upgrades are needed, they may not be in the office, and the equipment used for upgrade operations may not be fixed, which cannot meet the upgrade needs in different scenarios. Summary of the Invention

[0004] This application provides a verification method, device, server, storage medium, and product for OTA upgrade operations to solve the problems of related technologies failing to meet upgrade requirements in different scenarios and having poor security.

[0005] The first aspect of this application provides a method for verifying OTA upgrade operations, including the following steps: when an upgrade command for a vehicle is detected, the user's email type is obtained; if the email type is a first type, a security verification code is generated based on a token bucket; if the email type is a second type, a security verification code is generated based on the value of the current window counter; and the OTA upgrade operation is verified based on the security verification code.

[0006] Optionally, if the email type is the first type, a security verification code is generated based on the token bucket, including: obtaining a target token from the token bucket; and asynchronously sending a verification request to the user's email address based on the target token, wherein the verification request carries the security verification code.

[0007] Optionally, obtaining a target token from the token bucket includes: obtaining the known number of emails sent in the user's mailbox within a first preset time period; removing the known number of tokens from the token bucket; and obtaining the target token according to a preset token addition rate when a token is detected in the token bucket.

[0008] Optionally, if the email type is the second type, a security verification code is generated based on the value of the current window counter, including: if the value of the current window counter is less than or equal to a preset value within a first preset time, a verification request is sent to the user's email according to a preset sending rate, and the value of the current window counter is incremented by one, wherein the verification request carries a security verification code.

[0009] Optionally, before obtaining the user's email type, the process also includes: triggering a verification event based on the upgrade instruction; querying the preset database within a second preset time period to see if a verification pass record exists; if it exists, controlling the vehicle to perform an OTA upgrade operation; otherwise, generating a random verification code and storing the random verification code in the preset database.

[0010] Optionally, the OTA upgrade operation is verified based on the security verification code, including: recognizing the security verification code entered by the user on the front-end page; if the security verification code and the random verification code are the same, the OTA upgrade operation is deemed to have passed the verification; otherwise, the OTA upgrade operation is deemed to have failed the verification.

[0011] A second aspect of this application provides a verification device for OTA upgrade operations, comprising: an acquisition module, configured to acquire the user's email type when an upgrade command is detected; a generation module, configured to generate a security verification code based on a token bucket when the email type is a first type, and generate a security verification code based on the value of the current window counter when the email type is a second type; and a verification module, configured to verify the OTA upgrade operation based on the security verification code.

[0012] Optionally, the generation module is further configured to obtain a target token from the token bucket; and asynchronously send a verification request to the user's email address based on the target token, wherein the verification request carries a security verification code.

[0013] Optionally, the generation module is further configured to obtain the known number of emails sent in the user's mailbox within a first preset time period; remove the known number of tokens from the token bucket; and, when a token is detected in the token bucket, obtain the target token according to a preset token addition rate.

[0014] Optionally, the generation module is further configured to send a verification request to the user's mailbox according to a preset sending rate if the value of the current window counter is less than or equal to a preset value within a first preset time period, and increment the value of the current window counter by one, wherein the verification request carries a security verification code.

[0015] Optionally, the verification device for OTA upgrade operations further includes: a triggering module, used to trigger verification items according to the upgrade instruction before obtaining the user's email type; and a judgment module, used to query whether there is a verification pass record in the preset database within a second preset time period according to the verification items. If there is, the vehicle is controlled to perform the OTA upgrade operation; otherwise, a random verification code is generated and stored in the preset database.

[0016] Optionally, the verification module is further used to identify the security verification code entered by the user on the front-end page; if the security verification code and the random verification code are the same, the OTA upgrade operation is deemed to have passed the verification; otherwise, the OTA upgrade operation is deemed to have failed the verification.

[0017] A third aspect of this application provides a server, including: a memory, a processor, and a computer program stored in the memory and executable on the processor. The processor executes the program to implement a verification method for OTA upgrade operations as described in the above embodiments.

[0018] A fourth aspect of this application provides a computer-readable storage medium having a computer program stored thereon, which is executed by a processor to implement a verification method for OTA upgrade operations as described in the above embodiments.

[0019] A fifth aspect of this application provides a computer program product, including: a computer program or instructions, which, when executed, implement a verification method for OTA upgrade operations as described in the above embodiments.

[0020] Therefore, this application has at least the following beneficial effects:

[0021] This application's embodiments can impose different frequency restrictions on different email types when a user's upgrade command is detected. This can meet various OTA upgrade scenarios and generate corresponding security verification codes based on different email types. The security verification codes are used to verify the OTA upgrade operation, ensuring its security. Therefore, this solves the problems of related technologies that cannot meet upgrade needs in different scenarios and have poor security.

[0022] Additional aspects and advantages of this application will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of this application. Attached Figure Description

[0023] The above and / or additional aspects and advantages of this application will become apparent and readily understood from the following description of the embodiments taken in conjunction with the accompanying drawings, wherein:

[0024] Figure 1 This is a flowchart of the verification method for OTA upgrade operations provided in the embodiments of this application;

[0025] Figure 2 This is an example diagram illustrating the verification of an OTA upgrade operation according to an embodiment of this application;

[0026] Figure 3 This is an example diagram of a verification device for OTA upgrade operations provided according to an embodiment of this application;

[0027] Figure 4 This is a schematic diagram of the structure of a server provided according to an embodiment of this application. Detailed Implementation

[0028] The embodiments of this application are described in detail below. Examples of these embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary and intended to explain this application, and should not be construed as limiting this application.

[0029] The following description, with reference to the accompanying drawings, outlines an OTA upgrade operation verification method, apparatus, server, storage medium, and product according to embodiments of this application. Addressing the problems mentioned in the background section, this application provides an OTA upgrade operation verification method. In this method, upon detecting a user's upgrade command, different frequency restrictions are applied to different email types. This satisfies various OTA upgrade scenarios and generates corresponding security verification codes based on the email type. The security verification codes are used to verify the OTA upgrade operation, ensuring its security. This solves the problems of related technologies failing to meet upgrade requirements in different scenarios and exhibiting poor security.

[0030] Specifically, Figure 1 This is a flowchart illustrating a verification method for OTA upgrade operations provided in an embodiment of this application.

[0031] like Figure 1 As shown, the verification method for this OTA upgrade operation includes the following steps:

[0032] In step S101, when an upgrade command for a vehicle is detected, the user's email address type is obtained.

[0033] Understandably, when users perform OTA upgrades on the management platform, they can click the upgrade button on the platform to generate upgrade instructions and perform different verification operations based on the user's email type, ensuring the stability and security of the user's OTA upgrade operation.

[0034] In one embodiment of this application, before obtaining the user's email type, this embodiment of the application can trigger a verification item according to the upgrade instruction; according to the verification item, query whether there is a verification passed record in the preset database within a second preset time. If there is, control the vehicle to perform OTA upgrade operation; otherwise, generate a random verification code and store the random verification code in the preset database.

[0035] The preset database can be used for verification codes, verification records, and other information. The preset database can be selected according to the actual situation, such as Redis or SQL, without specific limitations. The second preset time can be set according to the actual situation, such as 24 hours, without specific limitations.

[0036] In this embodiment of the application, taking Redis as the preset database as an example, when the user clicks the upgrade button, the permission verification process can be triggered. At this time, the Redis will be queried to see if there is a record of the user's verification passed within 24 hours. If there is, the verification will be passed directly, and the user does not need to perform subsequent verification. The user can directly perform OTA upgrade related operations. Thus, the convenience of users in OTA upgrade operations can be guaranteed by the 24-hour verification-free method.

[0037] If the verification code does not exist, this embodiment of the application can generate a random verification code, such as a 4-digit number, and store it in Redis. To further ensure the security of the verification, this embodiment of the application can also set the random verification code to expire after 5 minutes. When the verification code expires, as a possible implementation method, this embodiment of the application can delete the verification code from the preset database, thereby reducing the server load rate.

[0038] In step S102, if the mailbox type is the first type, a security verification code is generated based on the token bucket; if the mailbox type is the second type, a security verification code is generated based on the value of the current window counter.

[0039] In this application embodiment, the email type can be divided into internal email and external email. In order to meet the upgrade operation requirements in different scenarios, this application embodiment has different restrictions on internal and external email. The first type can be an internal email, and the second type can be an external email.

[0040] In one embodiment of this application, if the email address type is a first type, generating a security verification code based on the token bucket includes: obtaining a target token from the token bucket; and asynchronously sending a verification request to the user's email address based on the target token, wherein the verification request carries a security verification code.

[0041] For internal email, such as Figure 2As shown, this application embodiment can implement the verification of the upgrade operation through a token. In this application embodiment, a target token can be obtained from the token bucket, including: obtaining the known number of emails sent in the user's mailbox within a first preset time; removing the known number of tokens from the token bucket; and obtaining the target token according to a preset token addition rate when a token is detected in the token bucket. The first preset time can be set to 1 minute, without specific limitation.

[0042] Specifically, the internal mailbox can limit the maximum sending frequency to 90 emails per minute. By combining the sliding window algorithm and the token bucket algorithm, both the email sending rate limit and the handling of burst traffic can be considered simultaneously. The specific implementation is as follows:

[0043] Token bucket size: The token bucket size is set to 90 tokens per minute, which is 1.5 tokens added per second. The preset token addition rate can be determined based on the token bucket size. For example, if the frequency of sending internal emails is limited to 90 emails per minute, the preset token addition rate is 1.5 tokens added per second.

[0044] When the system starts, the token bucket is initialized to empty. When an internal email sending request arrives, a token is first obtained from the token bucket. If no token is available in the token bucket, the request is rejected or queued for processing. If a token is successfully obtained, an email verification request is executed, and the sent email is recorded. The verification request includes a security verification code, which, in this embodiment, can be sent to the user's mailbox asynchronously via multi-threaded email sending.

[0045] In actual implementation, to ensure that a maximum of 90 emails are sent per minute, this embodiment of the application needs to record the emails already sent. A counter can be used to record the known number of emails sent, with an initial value of 0. The counter is incremented by 1 after each email sending request. At the end of each time unit (e.g., per second), a corresponding number of tokens are removed from the token bucket based on the number of emails sent. If the number of emails sent exceeds the limit (e.g., a maximum of 90 emails per minute), the corresponding number of tokens are removed, and subsequent requests are rejected or queued for processing.

[0046] It should be noted that the embodiments of this application can also flexibly adjust the size of the token bucket and the token addition rate according to actual business needs to adapt to different traffic changes.

[0047] In one embodiment of this application, if the email type is the second type, a security verification code is generated based on the value of the current window counter, including: if the value of the current window counter is less than or equal to a preset value within a first preset time, a verification request is sent to the user's email according to a preset sending rate, and the value of the current window counter is incremented by one, wherein the verification request carries a security verification code.

[0048] In this embodiment of the application, for external email addresses, such as Figure 2 As shown, this embodiment of the application can limit the preset sending rate to 3 emails per minute. For external mailbox rate limiting algorithms, since the sending frequency is low, a rate limiting algorithm is used to limit the number of emails sent per minute, specifically implemented as follows:

[0049] This embodiment limits the rate of external email sending to 3 emails per minute. Upon system startup, the counter is initialized to 0. When an external email sending request arrives, the value of the current window counter within one minute is first retrieved. If the counter value is less than 3, an email sending verification request is executed, and the counter is incremented by 1. If the counter value is equal to or greater than 3, the request is rejected or queued for processing until the counter value is cleared after a first preset time (i.e., after one minute), at which point the next step is executed.

[0050] The verification request includes a security verification code. In this embodiment, the security verification code can be sent to the user's email address via multi-threaded asynchronous email sending.

[0051] It should be noted that the preset sending rate of the external mailbox in this application embodiment can also be flexibly adjusted according to actual business needs to adapt to different traffic changes.

[0052] In summary, this application embodiment imposes different restrictions on internal and external email addresses, and will fail to send messages if the frequency exceeds a certain range. In combination with this scenario, different rate limiting algorithms are used to ensure the stability of users during OTA upgrade operations.

[0053] In step S103, the OTA upgrade operation is verified based on the security verification code.

[0054] In one embodiment of this application, the OTA upgrade operation is verified based on a security verification code, including: identifying the security verification code entered by the user on the front-end page; if the security verification code and the random verification code are the same, the OTA upgrade operation is determined to have passed the verification; otherwise, the OTA upgrade operation is determined to have failed the verification.

[0055] It is understood that, based on the above embodiments, after sending the security verification code to the user's email address, this application embodiment can identify the security verification code entered by the user on the front-end page, verify the security verification code, check whether the user and the security verification code match in Redis, and query the random verification code in Redis using the security verification code as an index. If this application embodiment can find a random verification code in Redis that matches the security verification code, the page will indicate that the verification is successful, and the user can perform OTA upgrade-related operations. The user's successful verification will be recorded in Redis, and this record will automatically expire after 24 hours, requiring the user to re-verify. If no code is found, this application embodiment will indicate that the entered security verification code is incorrect and end the verification, thereby ensuring the security of the user during OTA upgrade operations.

[0056] The OTA upgrade operation verification method proposed in this application implements different frequency restrictions for different email types when a user's upgrade command is detected. This satisfies various OTA upgrade scenarios and generates corresponding security verification codes based on the email type. The OTA upgrade operation is verified using these security verification codes, ensuring its security. This solves the problems of related technologies that cannot meet upgrade requirements in different scenarios and suffer from poor security.

[0057] Next, referring to the accompanying drawings, a verification device for OTA upgrade operations proposed according to an embodiment of this application is described.

[0058] Figure 3 This is a block diagram of the verification device for OTA upgrade operation according to an embodiment of this application.

[0059] like Figure 3 As shown, the verification device 10 for the OTA upgrade operation includes: an acquisition module 100, a generation module 200, and a verification module 300.

[0060] The acquisition module 100 is used to acquire the user's email type when an upgrade command is detected; the generation module 200 is used to generate a security verification code based on the token bucket when the email type is the first type, and to generate a security verification code based on the value of the current window counter when the email type is the second type; the verification module 300 is used to verify the OTA upgrade operation based on the security verification code.

[0061] In one embodiment of this application, the generation module 200 is further configured to obtain a target token from the token bucket; and asynchronously send a verification request to the user's email address based on the target token, wherein the verification request carries a security verification code.

[0062] In one embodiment of this application, the generation module 200 is further configured to obtain the known number of emails sent in the user's mailbox within a first preset time period; remove the known number of tokens from the token bucket; and when a token is detected in the token bucket, obtain the target token according to a preset token addition rate.

[0063] In one embodiment of this application, the generation module 300 is further configured to send a verification request to the user's mailbox according to a preset sending rate when the value of the current window counter is less than or equal to a preset value within a first preset time, and increment the value of the current window counter by one, wherein the verification request carries a security verification code.

[0064] In one embodiment of this application, the OTA upgrade operation verification device 10 further includes: a triggering module, used to trigger a verification item according to the upgrade instruction before obtaining the user's email type; and a judging module, used to query whether there is a verification pass record in the preset database within a second preset time period according to the verification item. If there is, the vehicle is controlled to perform the OTA upgrade operation; otherwise, a random verification code is generated and stored in the preset database.

[0065] In one embodiment of this application, the verification module 300 is further configured to identify the security verification code entered by the user on the front-end page; if the security verification code and the random verification code are the same, it is determined that the OTA upgrade operation has passed the verification; otherwise, it is determined that the OTA upgrade operation has failed the verification.

[0066] It should be noted that the explanation of the aforementioned verification method embodiment for OTA upgrade operations also applies to the verification device for OTA upgrade operations in this embodiment, and will not be repeated here.

[0067] According to the OTA upgrade operation verification device proposed in this application, when X detects a user's upgrade command, it imposes different frequency restrictions on different email types. This satisfies various OTA upgrade scenarios and generates corresponding security verification codes based on different email types. The OTA upgrade operation is verified using these security verification codes, ensuring the security of the OTA upgrade operation. This solves the problems of related technologies that cannot meet upgrade requirements in different scenarios and have poor security.

[0068] Figure 4 A schematic diagram of the structure of a server provided in an embodiment of this application. The server may include:

[0069] The memory 401, the processor 402, and the computer program stored on the memory 401 and capable of running on the processor 402.

[0070] When the processor 402 executes the program, it implements the verification method for OTA upgrade operations provided in the above embodiments.

[0071] Furthermore, the server also includes:

[0072] Communication interface 403 is used for communication between memory 401 and processor 402.

[0073] The memory 401 is used to store computer programs that can run on the processor 402.

[0074] The memory 401 may include high-speed RAM (Random Access Memory) memory, and may also include non-volatile memory, such as at least one disk storage.

[0075] If the memory 401, processor 402, and communication interface 403 are implemented independently, then the communication interface 403, memory 401, and processor 402 can be interconnected via a bus to complete communication between them. The bus can be an ISA (Industry Standard Architecture) bus, a PCI (Peripheral Component Interconnect) bus, or an EISA (Extended Industry Standard Architecture) bus, etc. The bus can be divided into address bus, data bus, control bus, etc. For ease of representation, Figure 4 The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.

[0076] Optionally, in a specific implementation, if the memory 401, processor 402, and communication interface 403 are integrated on a single chip, then the memory 401, processor 402, and communication interface 403 can communicate with each other through an internal interface.

[0077] Processor 402 may be a CPU (Central Processing Unit), an ASIC (Application Specific Integrated Circuit), or one or more integrated circuits configured to implement embodiments of this application.

[0078] This application also provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the above-described verification method for OTA upgrade operations.

[0079] This application also provides a computer program product, including: a computer program or instructions, which, when executed, implement a verification method for OTA upgrade operations as described in the above embodiments.

[0080] In the description of this specification, the references to terms such as "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of this application. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples. Moreover, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification, as well as the features of different embodiments or examples.

[0081] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one of that feature. In the description of this application, "N" means at least two, such as two, three, etc., unless otherwise explicitly specified.

[0082] Any process or method described in the flowchart or otherwise herein can be understood as representing a module, segment, or portion of code comprising one or more N executable instructions for implementing custom logic functions or processes, and the scope of the preferred embodiments of this application includes additional implementations in which functions may be performed not in the order shown or discussed, including substantially simultaneously or in reverse order depending on the functions involved, as should be understood by those skilled in the art to which embodiments of this application pertain.

[0083] It should be understood that the various parts of this application can be implemented using hardware, software, firmware, or a combination thereof. In the above embodiments, the N steps or methods can be implemented using software or firmware stored in memory and executed by a suitable instruction execution system. For example, if implemented in hardware, as in another embodiment, it can be implemented using any one or a combination of the following techniques known in the art: discrete logic circuits having logic gates for implementing logical functions on data signals, application-specific integrated circuits (ASICs) having suitable combinational logic gates, programmable gate arrays (FPGAs), field-programmable gate arrays (FPGAs), etc.

[0084] Those skilled in the art will understand that all or part of the steps of the methods described in the above embodiments can be implemented by a program instructing related hardware. The program can be stored in a computer-readable storage medium, and when executed, it includes one or a combination of the steps of the method embodiments.

[0085] Although embodiments of this application have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting this application. Those skilled in the art can make changes, modifications, substitutions and variations to the above embodiments within the scope of this application.

Claims

1. A method for verifying an OTA upgrade operation, characterized in that, The method comprises the following steps: Upon detecting an upgrade instruction of a vehicle, obtaining a mailbox type of a user; If the mailbox type is a first type, generating a security check code based on a token bucket, and if the mailbox type is a second type, generating the security check code based on a value of a current window counter, wherein the first type is an internal mailbox and the second type is an external mailbox; Verifying the OTA upgrade operation according to the security check code; If the mailbox type is the first type, generating the security check code based on the token bucket comprises: obtaining a target token from the token bucket; and sending a verification request to the user mailbox asynchronously according to the target token, wherein the verification request carries the security check code; If the mailbox type is the second type, generating the security check code based on the value of the current window counter comprises: if the value of the current window counter is less than or equal to a preset value within a first preset time, sending a verification request to the user mailbox according to a preset sending rate, and adding one to the value of the current window counter, wherein the verification request carries the security check code. Before obtaining the mailbox type of the user, the method further comprises:

2. The validation method of OTA upgrade operation according to claim 1, characterized in that, Triggering a verification matter according to the upgrade instruction; Querying whether a verification pass record exists in a preset database within a second preset time according to the verification matter, if the verification pass record exists, controlling the vehicle to perform the OTA upgrade operation, otherwise, generating a random check code and storing the random check code in the preset database. The verification of the OTA upgrade operation according to the security check code comprises:

3. The validation method of OTA upgrade operation according to claim 2, wherein, Identifying the security check code input by the user on a front-end page; If the security check code is the same as the random check code, determining that the verification of the OTA upgrade operation is passed, otherwise, determining that the verification of the OTA upgrade operation is not passed. The method comprises:

4. A verification device for OTA upgrade operation, characterized in that, A obtaining module, configured to obtain a mailbox type of a user upon detecting an upgrade instruction of the user; A generating module, configured to generate a security check code based on a token bucket if the mailbox type is a first type, and generate the security check code based on a value of a current window counter if the mailbox type is a second type, wherein the first type is an internal mailbox and the second type is an external mailbox; A verifying module, configured to verify an OTA upgrade operation according to the security check code; If the mailbox type is the first type, the generating module is further configured to: obtain a target token from the token bucket; and send a verification request to the user mailbox asynchronously according to the target token, wherein the verification request carries the security check code; ​ The generation module is further configured to: acquire a known number of sent emails in the user mailbox within a first preset time; remove the known number of tokens from the token bucket, and acquire the target token according to a preset token adding rate when it is detected that there is a token in the token bucket; If the mailbox type is the second type, the generation module is further configured to: if the value of the current window counter is less than or equal to a preset value within the first preset time, send a verification request to the user mailbox according to a preset sending rate, and add one to the value of the current window counter, wherein the verification request carries the security check code.

5. A server, characterized by Comprising: A memory, a processor, and a computer program stored on the memory and executable on the processor, the processor executing the program to implement the verification method of the OTA upgrade operation according to any one of claims 1-3.

6. A computer-readable storage medium having stored thereon a computer program, characterized in that, The program is executed by the processor to implement the verification method of the OTA upgrade operation according to any one of claims 1-3.

7. A computer program product, comprising: A computer program or instructions, characterized in that the computer program or instructions are executed to implement the verification method of the OTA upgrade operation according to any one of claims 1-3.

Images