Vehicle OTA abnormal upgrade alarm method, device and equipment and storage medium

Abstract

The invention provides a vehicle OTA abnormal upgrade alarm method, device and equipment and a medium, and belongs to the technical field of automobile intelligent upgrade.The method comprises the steps that all OTA controllers are marked, and the OTA controllers which have influences on vehicle starting and have no AB backup are screened out; marking all the OTA upgrade failure situations, and screening out the OTA upgrade failure situations which have influences on the functions of the OTA controller; formulating an OTA abnormal upgrade alarm list based on the screened OTA controller and the OTA upgrade failure condition; and matching the OTA abnormal upgrade alarm list with information reported in an OTA upgrade process, and if the reported information exists in the OTA abnormal upgrade alarm list, carrying out abnormal alarm. Through the technical scheme in the embodiment of the invention, alarm processing can be carried out when abnormal upgrading is detected.

Description

Technical Field

[0001] This invention relates to the field of automotive intelligent upgrade technology, and in particular to a method, device, equipment, and storage medium for vehicle OTA abnormal upgrade alarm. Background Technology

[0002] With the rapid development of intelligent connected vehicles, updating and upgrading in-vehicle software and firmware has become an important means to improve vehicle performance, fix vulnerabilities, and optimize user experience. Over-the-air (OTA) technology is a technology that enables remote system upgrades of devices via mobile or wireless networks, similar to system updates on smartphones or computers. It can complete updates without a physical connection and is increasingly being widely applied in the field of intelligent connected vehicles.

[0003] However, in practical applications, due to reasons such as network instability, software version compatibility issues, or operational errors, vehicle software or firmware upgrades may fail. If an upgrade fails without A / B backup, the upgraded software or firmware function will be unusable. More seriously, a failed power domain controller upgrade can prevent the vehicle from starting normally, rendering the vehicle unusable and causing significant inconvenience and safety hazards.

[0004] Therefore, there is an urgent need for a processing mechanism that can detect vehicle OTA upgrades in real time and issue alarms when abnormal upgrades are detected. Summary of the Invention

[0005] The present invention aims to solve at least one of the technical problems existing in the prior art, and proposes a method, device, equipment and storage medium for vehicle OTA abnormal upgrade alarm.

[0006] In a first aspect, embodiments of the present invention provide a method for alarming abnormal vehicle OTA upgrades, including:

[0007] All OTA controllers are tagged, and those that affect vehicle startup and have no A / B backup are selected.

[0008] Mark all OTA upgrade failure scenarios and filter out those that affect the OTA controller functionality;

[0009] Based on the selected OTA controllers and OTA upgrade failure scenarios, a list of abnormal OTA upgrade alarms is compiled.

[0010] The OTA abnormal upgrade alarm list is matched with the information reported during the OTA upgrade process. If the reported information exists in the OTA abnormal upgrade alarm list, an abnormal alarm is issued.

[0011] In some embodiments, prior to screening the OTA controller, the method further includes:

[0012] OTA controllers are classified based on their functional domains.

[0013] Determine whether each functional domain affects vehicle starting.

[0014] In some embodiments, marking all OTA upgrade failure scenarios includes:

[0015] Based on the stage, type, and cause of OTA upgrade failure, different error codes are constructed for marking; the error codes are used to indicate the stage, type, and cause of failure corresponding to abnormal OTA upgrade of the vehicle.

[0016] In some embodiments, the occurrence phase includes: a task detection phase, a task download phase, a pre-upgrade phase, an upgrade phase, and a post-upgrade phase.

[0017] In some embodiments, the process of creating an OTA abnormal upgrade alarm list includes:

[0018] OTA controllers that pose a risk of any of the marked OTA upgrade failure scenarios are selected from the marked OTA controllers and then marked again;

[0019] After mapping and summarizing the OTA controllers marked with secondary tags and the corresponding OTA upgrade failure scenarios, the list of abnormal OTA upgrade alarms is completed.

[0020] In some embodiments, matching the OTA abnormal upgrade alarm list with the information reported during the OTA upgrade process includes:

[0021] OTA platforms deploy OTA upgrade tasks to vehicles;

[0022] When the conditions for downloading the OTA upgrade task are met, the vehicle will download and execute the OTA upgrade task.

[0023] After the vehicle upgrade is completed, it will report the list of OTA controllers and the upgrade result code to the OTA platform.

[0024] The OTA platform checks whether the information reported this time is in the OTA abnormal upgrade alarm list.

[0025] In some embodiments, the OTA upgrade task download conditions include: network status, storage space, and task validity period.

[0026] Secondly, embodiments of the present invention provide a vehicle OTA abnormal upgrade alarm device, comprising:

[0027] The first filtering module is used to mark all OTA controllers and filter out OTA controllers that have an impact on vehicle startup and have no A / B backup.

[0028] The second filtering module is used to mark all OTA upgrade failure scenarios and filter out OTA upgrade failure scenarios that affect the OTA controller function.

[0029] The list creation module is used to create a list of OTA abnormal upgrade alarms based on the selected OTA controllers and OTA upgrade failure scenarios;

[0030] The abnormal alarm module is used to match the OTA abnormal upgrade alarm list with the information reported during the OTA upgrade process. If the reported information exists in the OTA abnormal upgrade alarm list, an abnormal alarm is triggered.

[0031] Thirdly, embodiments of the present invention provide an electronic device, the electronic device comprising:

[0032] At least one processor; and a memory communicatively connected to the at least one processor;

[0033] The memory stores a computer program that can be executed by at least one processor, such that the at least one processor is able to perform the steps of the method according to any embodiment of the present invention.

[0034] Fourthly, embodiments of the present invention provide a computer-readable storage medium storing computer instructions that are used to cause a processor to execute the steps of any embodiment of the method of the present invention.

[0035] Compared with the prior art, the present invention has the following advantages:

[0036] The vehicle OTA abnormal upgrade alarm method provided by this invention first marks all OTA controllers and filters out OTA controllers that affect vehicle startup and lack A / B backup; then, it marks all OTA upgrade failure scenarios and filters out OTA upgrade failure scenarios that affect the function of the OTA controllers; next, based on the filtered OTA controllers and OTA upgrade failure scenarios, it creates an OTA abnormal upgrade alarm list; finally, it matches the OTA abnormal upgrade alarm list with the information reported during the OTA upgrade process, and if the reported information exists in the OTA abnormal upgrade alarm list, an abnormal alarm is triggered. Through the technical solution of this invention, the vehicle OTA upgrade status can be detected in real time, and an alarm can be triggered when an upgrade failure is detected, thereby avoiding vehicle startup problems caused by upgrade failure. Attached Figure Description

[0037] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only preferred embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0038] Figure 1 This is a flowchart illustrating a method for issuing an abnormal OTA upgrade alarm for a vehicle, as provided in an embodiment of the present invention.

[0039] Figure 2 This is a schematic diagram of the vehicle side during an OTA upgrade, provided by an embodiment of the present invention.

[0040] Figure 3 A schematic diagram of an OTA platform for vehicle OTA upgrades provided in an embodiment of the present invention;

[0041] Figure 4 This is a schematic diagram of a mobile device during a vehicle OTA upgrade, provided as an embodiment of the present invention.

[0042] Figure 5 This is a structural block diagram of a vehicle OTA abnormal upgrade alarm device provided in an embodiment of the present invention;

[0043] Figure 6 This is a structural block diagram of an electronic device provided in an embodiment of the present invention. Detailed Implementation

[0044] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0045] To enable those skilled in the art to better understand the technical solutions of the present invention, exemplary embodiments of the present invention are described below in conjunction with the accompanying drawings, including various details of the embodiments of the present invention to aid understanding. These should be considered merely exemplary. Therefore, those skilled in the art should recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope and spirit of the present invention. Similarly, for clarity and brevity, descriptions of well-known functions and structures are omitted in the following description.

[0046] Where there is no conflict, the various embodiments of the present invention and the features thereof may be combined with each other.

[0047] As used herein, the term “and / or” includes any and all combinations of one or more related enumerated entries.

[0048] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the invention. As used herein, the singular forms “a” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will also be understood that when the terms “comprising” and / or “made of” are used in this specification, the presence of the stated feature, integral, step, operation, element, and / or component is specified, but the presence or addition of one or more other features, integrals, steps, operations, elements, components, and / or groups thereof is not excluded. Terms such as “connected” or “linked” are not limited to physical or mechanical connections but can include electrical connections, whether direct or indirect.

[0049] Unless otherwise specified, all terms used herein (including technical and scientific terms) have the same meaning as commonly understood by one of ordinary skill in the art. It will also be understood that terms such as those defined in commonly used dictionaries should be interpreted as having the meaning consistent with their meaning in the context of the relevant art and the invention, and will not be interpreted as having an idealized or overly formal meaning unless expressly so defined herein.

[0050] In the technical solution of this invention, the collection, storage, use, processing, transmission, provision, and disclosure of user personal information all comply with relevant laws and regulations and do not violate public order and good morals. The use of user data in this technical solution follows relevant national laws and regulations (e.g., the "Information Security Technology - Personal Information Security Specification"). For example: appropriate measures are taken for personal information access control; restrictions are imposed on the display of personal information; the purpose of using personal information does not exceed the scope of direct or reasonable association; and explicit identity targeting is eliminated when using personal information to avoid precisely locating a specific individual.

[0051] Before introducing the technical solution in this embodiment, it should be noted that at least one objective of the present invention is to provide an alarm mechanism for vehicles that cannot start due to OTA upgrade failure. This mechanism detects abnormal states during the OTA upgrade process in real time and triggers an alarm when an upgrade failure is detected, thereby avoiding the problem of vehicles being unable to start due to upgrade failure.

[0052] Figure 1 This is a flowchart illustrating a vehicle OTA abnormal upgrade alarm method provided in an embodiment of the present invention. This method is applicable to the situation of performing a whole vehicle OTA upgrade. This method can be executed by a vehicle OTA abnormal upgrade alarm device, which can be implemented in software and / or hardware and can be configured in an electronic device.

[0053] like Figure 1 As shown, the method specifically includes:

[0054] S1, mark all OTA controllers and filter out OTA controllers that have an impact on vehicle startup and have no AB backup.

[0055] It should be noted that the OTA controller that affects vehicle starting refers to the controller that directly or indirectly controls vehicle starting, or whose malfunction directly or indirectly causes abnormal vehicle starting. The vehicle starting process involves the coordinated operation of multiple controllers, and the failure of some controllers may directly or indirectly lead to abnormal starting.

[0056] In some embodiments, before screening OTA controllers, the method further includes: classifying OTA controllers based on their functional domains; and determining whether each functional domain has an impact on vehicle startup.

[0057] The OTA controller uses a domain controller as its core. The domain controller needs to interact with ECUs in the powertrain, chassis, and cockpit domains via the UDS protocol (distributed architecture) or the HTTP / SOME / IP protocol (SOA architecture). Traditional automobiles can have hundreds of controllers distributed across different communication networks with varying protocols, making OTA upgrades require coordination across multiple nodes, which is extremely risky and complex.

[0058] In this embodiment of the invention, by integrating the functions of multiple traditional controllers through a domain controller, the number of controllers can be significantly reduced, the complexity of OTA can be decreased, and it can be used to determine whether various functional domains have an impact on vehicle startup. Based on the determination results, the OTA controllers corresponding to the functional domains that have an impact on vehicle startup can be efficiently selected even when the number of controllers is large.

[0059] For example, Table 1 is a classification table of controller functional domains. As shown in Table 1, there are at least three functional domains: cockpit domain, intelligent driving domain, and powertrain domain. Under normal circumstances, OTA controllers belonging to the powertrain domain will affect vehicle startup, while OTA controllers belonging to the cockpit domain and intelligent driving domain will not affect vehicle startup.

[0060] Specifically, OTA controllers are classified according to their functional domains to determine whether each controller has AB backup function and whether it affects vehicle starting. This helps to determine the impact of controller upgrade failure and facilitates the development of subsequent upgrade failure alarm strategies.

[0061] Table 1: Controller Functional Domain Classification Table

[0062]

[0063] S2 marks all OTA upgrade failure scenarios and filters out OTA upgrade failure scenarios that affect the OTA controller function.

[0064] It should be noted that OTA upgrade failures that affect controller functionality refer to upgrade failures that directly or indirectly cause abnormal controller functionality.

[0065] All OTA upgrade failures are flagged, including by constructing different error codes based on the stage, type, and cause of the failure. The error codes indicate the stage, type, and cause of the abnormal OTA upgrade.

[0066] The failure stages include: task detection stage, task download stage, pre-upgrade stage, during-upgrade stage, and post-upgrade stage; failure types include: detection failure type, download failure type, pre-upgrade prerequisites not met type, pre-upgrade installation environment preparation failure type, during-upgrade failure type, and post-upgrade version information mismatch type; failure reasons include: network or other reasons, gear not in P gear, vehicle speed not 0, insufficient battery, task expired, upgrade package verification failure, failure to enter OTA mode, controller detection of flashing conditions failure, data erasure process failure, data download process failure, data transmission process failure, and failure to read part information after upgrade completion.

[0067] For example, Table 2 is a classification table of OTA upgrade failure scenarios. As shown in Table 2, the failure scenarios can be classified from the following aspects:

[0068] 1) Occurrence Phase. Issues during the task detection and download phases have no impact on the vehicle and are imperceptible to the user, requiring no intervention.

[0069] 2) Failure Type. Problems that occur after the upgrade begins, if they are issues during the pre-installation verification or environment preparation phase before the actual flashing, will not affect the controller's functionality regardless of whether the controller has A / B backups.

[0070] 3) Reasons for failure. Failure that has already entered the flashing process will not affect the controller's functionality if the failure is due to a failure to check the flashing conditions. However, failure during the data erasure, download, or transmission stages will lead to a bug in the controller's current partition software. If there is no A / B backup, the controller's functionality will be abnormal.

[0071] Table 2: Classification of OTA Upgrade Failure Scenarios

[0072]

[0073] S3, based on the selected OTA controllers and OTA upgrade failure scenarios, creates a list of OTA abnormal upgrade alarms.

[0074] Develop an OTA abnormal upgrade alarm list, including: selecting OTA controllers from the marked OTA controllers that have the risk of any of the marked OTA upgrade failure scenarios, and marking them a second time; mapping the second-marked OTA controllers and their corresponding OTA upgrade failure scenarios and summarizing them to complete the development of the OTA abnormal upgrade alarm list.

[0075] For example, Table 3 is a list of OTA abnormal upgrade alarms. As shown in Table 3, by combining the selected OTA controllers and OTA upgrade failure scenarios, it is determined which controllers and which types of failures require alarms. OTA controllers that affect vehicle startup and lack A / B backups, and which cause OTA controller malfunctions, are included in the OTA abnormal upgrade alarm list.

[0076] Table 3: List of OTA Abnormal Upgrade Alarms

[0077]

[0078] S4 matches the OTA abnormal upgrade alarm list with the information reported during the OTA upgrade process. If the reported information exists in the OTA abnormal upgrade alarm list, an abnormal alarm is issued.

[0079] The OTA abnormal upgrade alarm list is matched with the information reported during the OTA upgrade process, including: the OTA platform deploying the OTA upgrade task to the vehicle; the vehicle downloading and executing the OTA upgrade task when the download conditions are met; the vehicle reporting the OTA controller list and upgrade result code to the OTA platform after the upgrade is completed; and the OTA platform checking whether the reported information is in the OTA abnormal upgrade alarm list. The OTA upgrade task download conditions include: network status, storage space, and task validity period.

[0080] Specifically, the vehicle OTA upgrade process is completed collaboratively by the vehicle, the OTA platform, and the mobile device. Figure 2 This is a schematic diagram of a vehicle-side OTA upgrade provided by an embodiment of the present invention, as shown below. Figure 2 As shown, the vehicle-side includes: a Telematics Control Unit (TBOX) and an In-Vehicle Infotainment System (IVI). The TBOX can send commands to the UC-Slave integrated within the IVI via an interface program; the UC-Slave can send a scheduled upgrade time to the UC-Master; the UC-Master communicates with the OTA platform and, upon receiving an upgrade message, determines whether the upgrade conditions are met.

[0081] Among them, UC-Master is the core program for vehicle OTA upgrades, implementing the main control logic for OTA. It calls DM-Client to achieve business communication with the server and download software packages, and controls and manages other physical or virtual ECUs through the control and management of UC-Slave. UC-Slave is the control program for the upgraded ECU, mainly responsible for the management and control of a single ECU or the upgrade target.

[0082] Figure 3 This is a schematic diagram of an OTA platform for vehicle OTA upgrades provided in an embodiment of the present invention, as shown below. Figure 3 As shown, the OTA platform includes: an OTA management platform, a messaging service, and an OTA interface server. The messaging service establishes an information channel between the OTA management platform and the OTA interface server; the OTA management platform can push upgrade results to the mobile device; and the OTA interface server can interact with the UC-Master in the IVI (Internet Interface System).

[0083] Figure 4 This is a schematic diagram of a mobile device during a vehicle OTA upgrade, provided by an embodiment of the present invention. Figure 4 As shown, the mobile terminal includes: a mobile app, a mobile app server, and a TSP platform. The TSP platform communicates with the OTA management platform within the OTA platform and presents the upgrade results to the mobile app via the mobile app server.

[0084] The entire vehicle OTA upgrade process is as follows:

[0085] 1) Configure the alarm list on the OTA platform, and set the list of controllers that need to be alarmed and the error code types;

[0086] 2) Deployment of marketing activity upgrade tasks on OTA platforms;

[0087] 3) When the vehicle is powered on and the upgrade task is detected, and the network status, storage space, task validity period, etc. meet the download conditions, the upgrade task will begin to be downloaded;

[0088] 4) The vehicle-side operator sets up reservation tasks through the HMI interface. The UC-Slave synchronizes the reservation settings to the TBOX, which then maintains the reservation clock and receives and processes the data.

[0089] 5) The TBOX maintains the timer and attempts to power on the vehicle when the time arrives. After successful power-on, it sends the upgrade command to the UC-Master.

[0090] 6) UC-Master executes the upgrade action. After the verification of task validity, installation package decryption and signature, controller version information, and prerequisites are passed, the controller upgrade process begins.

[0091] 7) After the upgrade is completed, the vehicle will report the list of controllers upgraded and the upgrade result code to the OTA platform;

[0092] 8) Check if the information reported this time is in the alarm list on the OTA platform. If so, immediately notify the after-sales maintenance task of the vehicle upgrade information via email, SMS or enterprise communication software message. The after-sales service will contact the car owner in time to provide emergency assistance.

[0093] The technical solution in this invention provides a comprehensive and reliable automatic alarm mechanism for OTA upgrade failures, effectively reducing customer complaints caused by vehicle startup failures due to upgrade failures. By categorizing failure causes in detail and combining multi-channel alarm prompts and emergency handling measures, vehicle safety and user experience are significantly improved. Furthermore, the fault data recording and uploading function provides valuable data support for subsequent technical improvements.

[0094] Based on the same inventive concept, embodiments of the present invention also provide a vehicle OTA abnormal upgrade alarm device. Figure 5 This is a structural block diagram of a vehicle OTA abnormal upgrade alarm device provided in an embodiment of the present invention, as shown below. Figure 5 As shown, the device specifically includes:

[0095] The first screening module 100 is used to mark all OTA controllers and screen out OTA controllers that have an impact on vehicle startup and have no AB backup.

[0096] The second filtering module 200 is used to mark all OTA upgrade failure scenarios and filter out OTA upgrade failure scenarios that affect the OTA controller function.

[0097] The list creation module 300 is used to create an OTA abnormal upgrade alarm list based on the selected OTA controllers and OTA upgrade failure scenarios;

[0098] The abnormal alarm module 400 is used to match the OTA abnormal upgrade alarm list with the information reported during the OTA upgrade process. If the reported information exists in the OTA abnormal upgrade alarm list, an abnormal alarm will be issued.

[0099] The technical solution in this invention constructs a complete alarm mechanism for vehicles that cannot start due to OTA upgrade failure through the collaborative processing between various modules. This aims to reduce vehicle safety issues caused by upgrades and improve user experience.

[0100] Based on the same inventive concept, embodiments of the present invention also provide an electronic device. Figure 6This is a structural block diagram of an electronic device provided in an embodiment of the present invention. Figure 6 As shown, an embodiment of the present invention provides an electronic device including: one or more processors 101, a memory 102, and one or more I / O interfaces 103. The memory 102 stores one or more programs, which, when executed by the one or more processors, cause the one or more processors to implement any of the vehicle OTA abnormal upgrade alarm methods described in the above embodiments; the one or more I / O interfaces 103 are connected between the processor and the memory, configured to enable information interaction between the processor and the memory.

[0101] The processor 101 is a device with data processing capabilities, including but not limited to a central processing unit (CPU); the memory 102 is a device with data storage capabilities, including but not limited to random access memory (RAM, more specifically SDRAM, DDR, etc.), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), and flash memory (FLASH); the I / O interface (read / write interface) 103 is connected between the processor 101 and the memory 102, and can realize information interaction between the processor 101 and the memory 102, including but not limited to a data bus (BUS).

[0102] In some embodiments, the processor 101, memory 102, and I / O interface 103 are interconnected via bus 104, and thus connected to other components of the computing device.

[0103] In some embodiments, the one or more processors 101 include a field-programmable gate array.

[0104] This invention also provides a computer-readable medium. The computer-readable medium stores a computer program, which, when executed by a processor, implements the steps of any of the vehicle OTA abnormal upgrade alarm methods described in the above embodiments. The computer-readable storage medium can be volatile or non-volatile.

[0105] This invention also provides a computer program product, including computer-readable code, or a non-volatile computer-readable storage medium carrying computer-readable code. When the computer-readable code is run in the processor of an electronic device, the processor in the electronic device executes the above-described vehicle OTA abnormal upgrade alarm method.

[0106] Those skilled in the art will understand that all or some of the steps, systems, and apparatuses disclosed above, and their functional modules / units, can be implemented as software, firmware, hardware, or suitable combinations thereof. In hardware implementations, the division between functional modules / units mentioned above does not necessarily correspond to the division of physical components; for example, a physical component may have multiple functions, or a function or step may be performed collaboratively by several physical components. Some or all physical components may be implemented as software executed by a processor, such as a central processing unit, digital signal processor, or microprocessor, or as hardware, or as an integrated circuit, such as an application-specific integrated circuit (ASIC). Such software can be distributed on a computer-readable storage medium, which may include computer storage media (or non-transitory media) and communication media (or transient media).

[0107] As is known to those skilled in the art, the term computer storage medium includes volatile and non-volatile, removable and non-removable media implemented in any method or technology for storing information, such as computer-readable program instructions, data structures, program modules, or other data. Computer storage media includes, but is not limited to, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), static random access memory (SRAM), flash memory or other memory technologies, portable compact disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical disc storage, magnetic cartridges, magnetic tape, disk storage or other magnetic storage devices, or any other medium that can be used to store desired information and is accessible to a computer. Furthermore, it is known to those skilled in the art that communication media typically contain computer-readable program instructions, data structures, program modules, or other data in modulated data signals such as carrier waves or other transmission mechanisms, and may include any information delivery medium.

[0108] The computer-readable program instructions described herein can be downloaded from computer-readable storage media to various computing / processing devices, or downloaded via a network, such as the Internet, local area network, wide area network, and / or wireless network, to an external computer or external storage device. The network may include copper transmission cables, fiber optic transmission, wireless transmission, routers, firewalls, switches, gateway computers, and / or edge servers. A network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and forwards them to the computer-readable storage media in the respective computing / processing device.

[0109] The computer program instructions used to perform the operations of this invention may be assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state setting data, or source code or object code written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Smalltalk, C++, etc., and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The computer-readable program instructions may be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving a remote computer, the remote computer may be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or may be connected to an external computer (e.g., via the Internet using an Internet service provider). In some embodiments, electronic circuitry, such as programmable logic circuitry, field-programmable gate arrays (FPGAs), or programmable logic arrays (PLAs), is personalized by utilizing state information from the computer-readable program instructions. This electronic circuitry can execute the computer-readable program instructions to implement various aspects of the invention.

[0110] The computer program product described herein can be implemented specifically through hardware, software, or a combination thereof. In one alternative embodiment, the computer program product is specifically embodied in a computer storage medium; in another alternative embodiment, the computer program product is specifically embodied in a software product, such as a software development kit (SDK), etc.

[0111] Various aspects of the present invention are described herein with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It should be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer-readable program instructions.

[0112] These computer-readable program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to produce a machine such that, when executed by the processor of the computer or other programmable data processing apparatus, they create means for implementing the functions / actions specified in one or more blocks of the flowchart and / or block diagram. These computer-readable program instructions can also be stored in a computer-readable storage medium that causes a computer, programmable data processing apparatus, and / or other device to operate in a particular manner; thus, the computer-readable medium storing the instructions comprises an article of manufacture that includes instructions for implementing aspects of the functions / actions specified in one or more blocks of the flowchart and / or block diagram.

[0113] Computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable data processing apparatus, or other device to produce a computer-implemented process, thereby causing the instructions executed on the computer, other programmable data processing apparatus, or other device to perform the functions / actions specified in one or more boxes of a flowchart and / or block diagram.

[0114] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of an instruction, which contains one or more executable instructions for implementing a specified logical function. In some alternative implementations, the functions marked in the blocks may occur in a different order than those shown in the drawings. For example, two consecutive blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, may be implemented using a dedicated hardware-based system that performs the specified function or action, or using a combination of dedicated hardware and computer instructions.

[0115] Example embodiments have been disclosed herein, and while specific terminology has been used, it is for illustrative purposes only and should be construed as such, and is not intended to be limiting. In some instances, it will be apparent to those skilled in the art that features, characteristics, and / or elements described in conjunction with particular embodiments may be used alone, or in combination with features, characteristics, and / or elements described in conjunction with other embodiments, unless otherwise expressly indicated. Therefore, those skilled in the art will understand that various changes in form and detail may be made without departing from the scope of the invention as set forth in the appended claims.

Claims

1. A method for issuing alarms for abnormal OTA upgrades in vehicles, characterized in that, include: All OTA controllers are tagged, and those that affect vehicle startup and have no A / B backup are selected. Mark all OTA upgrade failure scenarios and filter out those that affect the OTA controller functionality; Based on the selected OTA controllers and OTA upgrade failure scenarios, a list of abnormal OTA upgrade alarms is compiled. The OTA abnormal upgrade alarm list is matched with the information reported during the OTA upgrade process. If the reported information exists in the OTA abnormal upgrade alarm list, an abnormal alarm is issued.

2. The method according to claim 1, characterized in that, Before filtering OTA controllers, the following is also included: OTA controllers are classified based on their functional domains. Determine whether each functional domain affects vehicle starting.

3. The method according to claim 1, characterized in that, The process of marking all OTA upgrade failure scenarios includes: Based on the stage, type, and cause of OTA upgrade failure, different error codes are constructed for marking; the error codes are used to indicate the stage, type, and cause of failure corresponding to abnormal OTA upgrade of the vehicle.

4. The method according to claim 3, characterized in that, The occurrence phases include: task detection phase, task download phase, pre-upgrade phase, during-upgrade phase, and post-upgrade phase.

5. The method according to claim 1, characterized in that, The aforementioned list of OTA abnormal upgrade alarms includes: OTA controllers that pose a risk of any of the marked OTA upgrade failure scenarios are selected from the marked OTA controllers and then marked again; After mapping and summarizing the OTA controllers marked with secondary tags and the corresponding OTA upgrade failure scenarios, the list of abnormal OTA upgrade alarms is completed.

6. The method according to claim 1, characterized in that, The process of matching the OTA abnormal upgrade alarm list with the information reported during the OTA upgrade process includes: OTA platforms deploy OTA upgrade tasks to vehicles; When the conditions for downloading the OTA upgrade task are met, the vehicle will download and execute the OTA upgrade task. After the vehicle upgrade is completed, it will report the list of OTA controllers and the upgrade result code to the OTA platform. The OTA platform checks whether the information reported this time is in the OTA abnormal upgrade alarm list.

7. The method according to claim 6, characterized in that, The download conditions for the OTA upgrade task include: network status, storage space, and task validity period.

8. A vehicle OTA abnormal upgrade alarm device, characterized in that, The apparatus is configured to implement the method according to any one of claims 1-7, the apparatus comprising: The first filtering module is used to mark all OTA controllers and filter out OTA controllers that have an impact on vehicle startup and have no A / B backup. The second filtering module is used to mark all OTA upgrade failure scenarios and filter out OTA upgrade failure scenarios that affect the OTA controller function. The list creation module is used to create a list of OTA abnormal upgrade alarms based on the selected OTA controllers and OTA upgrade failure scenarios; The abnormal alarm module is used to match the OTA abnormal upgrade alarm list with the information reported during the OTA upgrade process. If the reported information exists in the OTA abnormal upgrade alarm list, an abnormal alarm is triggered.

9. An electronic device, characterized in that, The electronic device includes: At least one processor, and a memory communicatively connected to said at least one processor; The memory stores a computer program that can be executed by the at least one processor to enable the at least one processor to perform the steps of the method according to any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions that cause a processor to perform the steps of the method according to any one of claims 1-7.

Images