System and procedure for updating software

Abstract

Techniques for facilitating a software update of a controller are disclosed. An over-the-air software update is installed using a dual-processor component system that discretely updates one processor at a time to a newer version of software. While the first processor is updated, the second processor monitors the software update to verify successful installation. The proposed OTA software update procedure is capable of automatically recovering the previous working software version in case the update procedure fails or the new version of the software is not working correctly.

Description

SYSTEM AND PROCEDURE FOR UPDATING SOFTWARE [1] FIELD OF THE DISCLOSURE[2] The present disclosure relates to systems, methods, and devices for updating software.[3] BACKGROUND[4] Like most mechanical equipment, air compressors require routine maintenance. In the industrial and manufacturing fields and critical infrastructures (i.e., healthcare (hospitals), waste water treatment, energy (power plants), maintenance is a standard procedure that amounts to part replacements and upgrades to hardware and software. This standard, periodic maintenance is performed on equipment that works consistently until it expires or becomes obsolete by newer technology. At facilities that employ high-tech machinery, such as rotary screw air compressors, preventative maintenance and fail-safe systems are needed to ensure the operability and longevity of all the expensive equipment on hand. Air compressors require reliable procedures to inspects the machines and update corresponding controller software regularly.[5] Controllers for compressors can optimize the operation of compressed air and blower systems in accordance with regulatory standards while pressure and flow setpoints are being met. These controllers also allow users to maximize energy savings and keep the equipment in good maintenance condition. Controllers also monitor compressor equipment for a proactive approach to maintenance and for live data visualization. Exemplary controllers for compressive systems include Optimizer 4.0, Equalizer 4.0, and Equalizer 4.0 PRO by Atlas Copco Compressors LLC. These controllers are ready for Industry 4.0, or the Internet of Things, and are designed for smart factories.[6] Elektronikon Nano by Atlas Copco Compressors LLC is another exemplary controller that offers “over-the-air” (OTA) updates for users. In previous controller systems, when controller updates became available, service technicians were sent to the end user’s site to manually perform and oversee an update. Because the end users are customers, they are unable and / or unauthorized to perform the update themselves. End users also lack the required expertise to fix a broken update. Ensuring that the compressor controller is installed with the latest software version via OTA updates, i.e., without the need of a visit from a service technician, ensures that the compressor is running at its optimum performance and that the equipment will retain more of its value, as well as the user’s capital investment.[7] Updates to controller software can be delivered OTA using a wireless network, such as via Wi-Fi or cellular network. OTA updates allow for software updates to be released as needed, which offers advantages in a world where software rapidly evolves. However, an OTA update can be interrupted, leaving the controller and the machine in a useless state as the old software has been partially or completely removed while the new software has not been properly installed. Alternatively, although an update may have been completed successfully, new software can suffer from undiscovered problems or bugs that prevent the machine from working correctly. These failed updates can impact both machines and businesses in the various fields. More particularly, failed OTA updates of compressor controller systems can affect production lines, assembly processes, quality assurance, etc. at facilities that employ the high-tech machinery of compressors. As such, there is a need for an OTA update procedure that is capable of automatically recovering the previous working software version in case the update procedure fails or the new version of the software is not working correctly.[8] Designing an OTA procedure to address this need poses two main problems. First, there is the issue of on-site or remote intervention in case of failed updates. There is a need for the recovery in case of failure to happen automatically, without requiring intervention from a service technician. It is desirable for the controller software managing the OTA update procedure to be able to detect that the new software version is not working correctly. Thus, there is a need for a detection mechanism to compare the state of the software after the update to the expected state in case of a successful update.[9] Second, there is an issue with the detection mechanism being integrated with a controller software that is being updated. The detection mechanism is ideally configured to verify that new functionality deployed via the update is working correctly. This is possible if the detection mechanism itself is also updated to include new verification procedures to verify the new software functionalities. As such, the detection mechanism should be tightly integrated with the rest of the updated controller software.

[10] Because the detection mechanism is responsible for detecting failures of the new software, there is a risk that failure of the update process, which prevents the new software from working correctly, might also cause the detection mechanism to fail. Thus, even if the controller software does not work correctly due to an improper update, there is a need for the detection mechanism in that software to always be able to detect the problem and recover the previous version of the software. The present disclosure provides an OTA software update system to remedy one or several of the above-mentioned and other disadvantages.

[11] SUMMARY

[12] The present disclosure presents a solution to OTA update procedures of the prior art by providing a dual component system, a monitoring mechanism, a rollback mechanism, and functional verification of newly added features added via the OTA update. The dual component system comprises two nodes (i.e., two processors), wherein the first node is responsible for monitoring the update of the second node and vice versa. Both nodes are thus updated and the controller software managing the update process is likewise updated. The dual component solution is adapted for both controller hardware and software. Controller hardware comprises two embedded processing units (PUs). The PU units can be two microcontroller units (MCUs), two microprocessor units (MPUs), or a mix (one MCU and one MPU), wherein each PU is running its own software.

[13] During an OTA update, the software of both PU components are not simultaneously updated. The system first updates the software of a first PU (referred to as PU A), during which the second PU (referred to as PU B) monitors the update of PU A, wherein the update of PU B is suspended. If the update of PU A fails, causing the software of PU A to fail, the software of PU B remains available to repair the software of PU A. On the other hand, if the update of PU A is successful, the software of PU B is then updated, during which PU A will monitor the update process and repair PU B software in case of an update failure.

[14] In other words, instead of updating all software at once (which can cause all software to fail after an update, including the software responsible to recover from update failure), the update is divided into two parts. In this way, it is guaranteed that there is always one dedicated software component operational at any given time during the update process and able to correct software failures due to the update. This is distinguishable over OTA updates in the prior art that mention a “gateway” or “OTA master” node that updates another node (e.g., an ECU) because prior art OTA updates fail to update of the gateway / master node itself. The solution described in the present disclosure allows for the complete system to upgrade, including the components that manage / monitor the update process. For this to work effectively, it is desirable for a software component to be present in both processing units’ software for monitoring the OTA procedure, detecting failures, and recovering operational software.

[15] In an embodiment, an OTA update monitor is implemented for each PU (i.e., PU A and PU B). The role of this software component, located and running on a given PU, is to monitor the update of the other PU, as well as to detect failures in the other PU’s software following the OTA update. When a failure is detected, the OTA update will trigger a rollback mechanism, reverting the updated PU software to the previous version that is known to work.

[16] To monitor the update of a PU, the update monitor must be able to communicate with the other PU. To enable this, PUs are connected via a communications channel, referred to as the inter-system communication (ISC) channel. The PUs notify each other of their status via the ISC channel. The OTA update monitor will check the ISC channel for status updates during and after the OTA update. A software failure in the updated PU will cause that PU to send abnormal status updates or no updates at all. This will be detected by the update monitor, which will then conclude that the update failed.

[17] To be able to act on such a failure, a so-called “PU update mode” is defined. Before the OTA update is started, the PU to be updated is put into an update mode. Next, the OTA update of that PU is performed, while the other PU monitors the update process. When the OTA update is complete, the updated PU remains in the update mode while the monitor on the other PU verifies the state of the updated PU by checking the ISC channel for status updates. Once the status updates via ISC indicate that the OTA update was successful, the updated PU is allowed to exit from the update mode. In this case, the update monitor will use the ISC channel to signal that the update was successful by sending a confirmation message via the ISC channel to the updated PU. This will cause the updated PU to exit from update mode. If the update fails or the updated software is not working correctly, the update mode is not deactivated and the updated PU is reset by the other PU, which will cause the updated PU to reboot. When the reset and reboot is performed while the PU is still in update mode, a rollback mechanism will be automatically triggered to recover the previous version of the software.

[18] To enable the reset of a PU by the OTA update monitor on the other PU, low-level hardware connections (e.g., reset lines) are implemented between the PUs. Importantly, these low-level connections operate on a hardware reset circuitry that is typically available both in MCUs and MPUs. This means that a PU can be reset even when the software on that PU does not work anymore. This is especially advantageous, as the OTA update procedure may lead to a software failure. The reset lines differ from the ISC channel in this regard, with the latter being dependent on the updated PU software to work correctly. The ISC channel is therefore not used to reset the updated PU. It is possible that the updated PU does not respond anymore after an OTA update, meaning that it will not act on data and commands that are sent via the ISC channel. However, in that case, the disclosed OTA update monitor allows for the PU to be reset via the low-level reset line.

[19] It should be noted that a PUs update mode status (e.g., enabled / disabled) is stored in the PU memory. This means that a reset and reboot will not change the mode of the PU. A PU in update mode remains in update mode after reset and reboot. This feature allows for the rollback mechanism, which is activated upon reset and reboot, to identify that the reset occurred in the context of a failed OTA update if the reset happens while update mode is still active.

[20] The rollback mechanism comprises a rollback evaluation procedure and a rollback operation. The disclosed rollback mechanism is implemented on both PUs and can recover the previous version of the software, using a rollback operation, in case the updated software fails to work. The rollback evaluation procedure is started each time a PU is started or restarted. Based on the outcome of the evaluation procedure, the rollback operation is started or not to restore a previous version of software. This means the rollback mechanism is started after a reset and reboot triggered by the OTA update monitor in case of a failed update, as described in the previous section. However, the evaluation procedure of the rollback mechanism will also be started when the system is started / rebooted under “normal” circumstances (i.e., not in the context of an OTA update, e.g., due to a power cycle of machine or controller). The first task of the rollback mechanism is therefore, using the evaluation procedure, to determine whether the startup (e.g., the boot) of the PU is occurring due to a reset following a failed OTA update, or whether the startup is a normal startup. The rollback operation should only be triggered in the case of a failed OTA update and not in the case of a normal startup. For this task, the rollback mechanism relies on the update mode status, which can be retrieved from PU memory. If update mode is active during the reboot of a PU, the reboot has been triggered by the OTA update monitor following a failed update. In that case, the rollback mechanism will restore the previous version of the software. If the PU is not in update mode, the rollback mechanism will take no action and the PU boot up will be considered as a normal boot. Note that the evaluation procedure of the rollback mechanism consists of checking whether the update mode is active, or in a more complex use-case, evaluating the state of a boot counter.

[21] It is possible that the PU is rebooted one or multiple times as part of the OTA update procedure. For example, it is possible that the OTA update involves writing the new software to PU memory and then restarting the PU to switch to the new software. In this case, the PU will be restarted and rebooted while still in update mode, so update mode being active does not mean the update has failed in this case. The solution is to implement a boot counter as part of the rollback mechanism. This boot counter, which is stored in PU memory, is augmented every time the PU is rebooted. The rollback mechanism will only trigger a rollback operation when the boot count is higher than one would expect from a normal OTA update. To be able to roll back and restore the previous software version, this previous version remains available on the PU. For this reason, whenever a new software version is installed through an OTA update, the old version is not removed but kept available in a dedicated backup slot in the PU memory.

[22] Regarding the functional verification of new features added via the OTA update procedure, existing systems either simply verify whether the OTA update file has been properly stored in a flash memory or wait for the updated component to respond after an update. Procedures and systems in the prior art fail to disclose a smart functional validation for testing the new functionalities added by the OTA update. Executing such a task requires an OTA update of the component managing the update (e.g., “gateway” or “OTA master”). Otherwise, the managing component will remain unaware of the new functionalities and will be unable to validate them. Additionally, embodiments having two nodes, wherein the first node manages the update, and the second node is being updated, and both nodes are updated via the OTA update, there is an issue of aligning the firmware of both nodes.

[23] The functional verification preferably includes both basic verification of existing and un-updated functionalities of a PU and smart verification of new functionalities provided by the OTA update. Preferably, the computer system performs a basic verification of the first PU by the second PU after the first PU has been updated to ensure that basic functions of the first PU are unaffected. It should be noted that at this point, the second PU can only perform a basic verification as it has not yet been updated. As such, the second PU is unaware of new functionalities added to the first PU via the update. Subsequently, the computer system performs a smart verification of the second PU by the first PU after the second PU has been updated to ensure that new functionalities are present and operable on the second PU. This is possible because the first PU was updated first and is thus aware of the new functionalities added to the second PU. When both first and second PU are updated, the computer system finally performs the smart verification of the first PU by the second PU to ensure that new functionalities are present and operable on the first PU.

[24] In the event that the smart verification fails to ensure that new functionalities are present and operable on the first processor, the second PU triggers the rollback procedure of the first PU to reinstate the previous version of software on the first PU and, subsequently, the rollback procedure of the second PU is triggered (e.g., either by itself or by the first PU) to reinstate the previous version of software on the second PU. Thus, a rollback operation is performed on both PUs to ensure software alignment between PUs.

[25] This summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. These and other features, aspects, and advantages of the present disclosure will become better understood regarding the following description, appended claims, and accompanying drawings.

[26] BRIEF DESCRIPTION OF THE DRAWINGS

[27] In order to describe the manner in which the advantages and features of the systems and methods described herein can be obtained, a more particular description of the embodiments briefly described above will be rendered by reference to specific embodiments thereof which are illustrated in the appended drawings. Understanding that these drawings depict only typical embodiments of the systems and methods described herein, and are not therefore to be considered to be limiting of their scope, certain systems and methods will be described and explained with additional specificity and detail through the use of the accompanying drawings in which:

[28] Figure 1A illustrates an exemplary system that facilitates an OTA software update for a controller;

[29] Figure 1B illustrates an exemplary system that facilitates a software update for a controller;

[30] Figure 2A illustrates a schematic diagram of the disclosed dual component system;

[31] Figure 2B illustrates a schematic diagram of the dual component system with an intermediary service; and

[32] Figure 3 illustrates a flowchart of the disclosed software update process.

[33] DEFINITIONS

[34] For ease of understanding the disclosed embodiments of the OTA software update procedure and associated method and system elements, a description of a few terms is necessary.

[35] The term ‘compressor’ refers to a machine that draws low-pressure gas from auxiliary storage as raw input and then outputs high-pressure gas, either for storage or to feed other processes. The terms ‘compressor’ and ‘compressive elements’ are not intended to be limiting in scope and may refer to positive displacement compressors and / or rotodynamic compressors and / or individual components of compressors.

[36] The term ‘computer storage media’ refers to physical storage media that store computer-executable instructions and / or data structures. Storage media, such as a digital data carrier, includes computer hardware, such as random access memory (RAM), read-only memory (ROM), electrically erasable programmable ROM (EEPROM), solid state drives (SSDs), flash memory, phase-change memory (PCM), optical disk storage, magnetic disk storage, and the like.

[37] The term ‘controller’ generally refers to a computerized command terminal comprising a collection of sensors and electrical components i.e., to regulate various compressive instruments or elements. Compressor controllers include at least one main processing unit with a graphical touch-screen interface and are adapted to monitor the instrumentation of various compressor elements (e.g., motors, rotors, filters, bearings, valves, pressure sensors, temperature sensors), including multiple compressors. Exemplary compressor controllers operate to control safe startup and shutdown processes, provide real-time information of compressor instrumentation, adjust power output of the motor(s), stabilize compressor operations, control process variables, alert and warn operators of issues, and / or initiate an automatic shutdown in case of unsafe conditions.

[38] The term ‘network’ refers to one or more data links that enable the wired or wireless transport of electronic data between computer systems and / or modules and / or other electronic devices.

[39] The term ‘over-the-air’, or ‘OTA’, generally refers to the wireless delivery (i.e., Wi-Fi, cellular network) of new software, firmware, or other data to an embedded system. These embedded systems include controllers, tablets, set-top boxes, and other telecommunications equipment.

[40] The term ‘processor’ or ‘processing unit’ refers to one or more devices, circuits, and / or processing cores configured to process data, such as computer program instructions, and includes personal computers, desktop computers, laptop computers, message processors, hand-held devices, multi-processor systems, microprocessor-based or programmable consumer electronics, network PCs, minicomputers, mainframe computers, mobile telephones, PDAs, tablets, pagers, routers, switches, and the like. Unless otherwise stated, references to a first processor may also apply to a second processor and vice versa.

[41] The term ‘rollback mechanism’ refers to a mechanism or process that is responsible for evaluating whether a restoration of previous software is required and subsequently triggering the restoration, if needed. As such, starting the rollback mechanism starts an evaluation process, and subsequently, based on the outcome of said evaluation process, either triggering the restoration operation or proceeding with a normal system book without a restoration. Thus, the term rollback mechanism is a combination of a rollback evaluation and a rollback operation. A rollback evaluation procedure is started each time a processor is started or restarted, and a rollback operation is triggered in the event of a failed software update. Unless otherwise specified, “triggering” the rollback mechanism generally refers to triggering the rollback operation to restore a previous version of software.

[42] The term ‘service’ refers to an automated program that is tasked with performing different actions based on input. As used herein, the terms ‘executable module,’ ‘executable component,’ ‘component,’ ‘module,’ ‘service,’ or ‘engine’ can refer to hardware processing units or to software objects, routines, or methods that may be executed on with the dual component system and / or the software update system.

[43] The term ‘software’ generally refers to computer-executable instructions, code, data, applications, programs, program modules, or the like maintained in or on any form or type of computer-readable media that is configured for storing computer-executable instructions or the like in a manner that is accessible to a computing device.

[44] As used herein, reference to any type of machine learning or artificial intelligence may include any type of machine learning algorithm or device, convolutional neural network(s), multilayer neural network(s), recursive neural network(s), deep neural network(s), decision tree model(s) (e.g., decision trees, random forests, and gradient boosted trees) linear regression model(s), logistic regression model(s), support vector machine(s) (SVM), artificial intelligence device(s), or any other type of intelligent computing system. Any amount of training data may be used (and perhaps later refined) to train the machine learning algorithm to dynamically perform the disclosed operations.

[45] When introducing elements in the appended claims, the articles “a,” “an,” “the,” and “said” are intended to mean there are one or more of the elements. The terms “comprising,” “including,” and “having” are intended to be inclusive and mean that there may be additional elements other than the listed elements.

[46] DETAILED DESCRIPTION

[47] Figure 1A illustrates an exemplary software update system 100 that facilitates an OTA software update for a controller 103. The software update system 100 utilizes a dual component system 101 comprising a first processor 102 and a second processor 104 embedded in the controller 103. The dual component system 101 (or dual-processor component system), being integrated at a terminal device (i.e., controller 103) is communicatively coupled to a network 107 for enabling the transfer of OTA software updates received from a software origination device 109. In an embodiment, the controller 103 controls and monitors the functionality of at least one tool 105 associated with the controller 103. The controller 103 preferably enables app control (i.e., using Bluetooth® connection on a smartphone, tablet, or computer) and monitoring of the tool 105. The tool 105 can be connected to the controller 103 via wire or wireless connection. In an embodiment, the tool 105 is a compressor, wherein the controller 103 is adapted to monitor the compressor and / or compressor elements (e.g., motors, rotors, filters, bearings, valves, pressure sensors, temperature sensors). In an exemplary embodiment, the controller 103 is integrated with the tool 105. The interface of the embedded dual component system 101 of the controller 103 can be accessed via a network connection to the tool 105 in the embodiment where the controller 103 is integrated in the tool 105. Thus, it is not necessary to physically interact with tool 105 in order to operate the controller 103. In an embodiment where the controller 103 is part of the tool 105, other tools that do not have an integrated tool controller can use the controller 103 integrated with the tool 105 via a network connection.

[48] The network 107 is communicatively coupled to the dual component system 101 and the software origination device. The network facilitates the transfer of a software update package, including a new version of software. In an embodiment, the first processor 102 is preselected to receive the software update first. However, the dual component system 101 may include a handshake protocol wherein the first processor 102 and the second processor 104 agree to which processor will receive and install the software update first. The software origination device 109 may be a device (i.e., computer) used by a software designer, engineer, manufacturer, or artificial intelligence to compose software of an application specific to the controller 103 and / or tool 105 and to develop an OTA software update package of the software. The OTA software update may be a complete installation file of a new version of the software. Depending on the device (i.e., controller 103) and / or customer preferences, the software update can be installed automatically or require the consent of its users.

[49] Figure 1A depicts the first processor 102 and second processor 104 as being embedded with the controller 103. The dual component system 101 comprises both the first processor 102 and the second processor 104. The dual component system 101 may be equipped with a communication interface (i.e., touchscreen interface, graphical user interface, display screen) on the controller 103 to communicate information between users and the dual component system 101. There may be one communication interface on the controller to communicate with both the first processor 102 and the second processor 104.

[50] Figure 1B depicts an alternative embodiment of the software update system 100 wherein the dual component system 101 is communicatively coupled to a central, physical server 111. The server 111 may comprise components typical of a physical server, such as a motherboard, processor, memory storage device, one or more hard drives, a power supply, and a network adapter or external network connection capability. The server 111 may store one or more packages of software updates. In an embodiment, the server 111 is an OTA server. The server 111 may establish a connection with a software origination device 109 to obtain a software update package of a new version of software. In an embodiment, the server 111 is physically connected to the controller 103 to manually conduct the update.

[51] Figure 1B also depicts the dual component system 101 as comprising more than two processors 102, 104, 115 embedded in a single controller 103, wherein each processor is configured to run its own software. The processors 102, 104, 115 may be configured to monitor one or more processors during the software update process described in this description, wherein a first processor 102 monitors the update of the second processor 104, the second processor 104 monitors the update of a third processor 115, and the third processor 115 monitors the software update of the first processor 102. One skilled in the art will readily recognize that additional processors may be added for redundancy, and that a first processor 102 can sequentially monitor both second and third processors 104, 115, and so on. During a software update, the software of the individual processors 102, 104, 115 is not updated simultaneously. Instead, each software package or update is discretely and sequentially installed on the processors 102, 104, 115. In an embodiment, the controller 103 is configured to interface with one or more tools 105, 113, wherein the controller 103 is communicatively coupled to the tools 105, 113.

[52] Figure 2A illustrates a schematic diagram of the disclosed dual component system 101. In a preferred embodiment, the dual component system 101 is integrated with a controller 103, wherein the dual component system 101 defines a computerized, module component that comprises at least two processors 102, 104 for assembly with or into the controller 103. The dual component system 101 comprises a first embedded processor 102 and a second embedded processor 104. The first and second processors 102, 104 can be two microcontroller units (MCUs), two microprocessor units (MPUs), or a mix (one MCU and one MPU). Each first and second processor 102, 104 is running its own software. During an OTA update, the software of both first and second processors 102, 104 is not updated simultaneously. Rather, each software installed on the first and second processors 102, 104 is discretely updated.

[53] During an update of the software for the first processor 102 (e.g., PU A), the second processor 104 (e.g., PU B) is not to be updated, i.e., the second processor 104 is prevented or excluded from being updated. Instead, the second processor 104 monitors the software update of the first processor 102 during installation of a software package on the first processor 102. If the software update of the first processor 102 fails, consequently causing the software of the first processor 102 to fail, the software of the second processor 104 remains available to repair the software of first processor 102. In instances where the update of the first processor 102 is successful, the existing software of the second processor 104 is subsequently updated with the new software package, during which the first processor 102 monitors the OTA update process and repairs the software of the second processor 104 in case of an update failure.

[54] Instead of updating all software at once, which can cause all software to fail after an update, including the software responsible to recover from update failure, the software update is divided into two (or more) discrete parts. In this way, it is guaranteed that there is always one dedicated software component from either the first processor 102 or the second processor 104 that is operational at any given time during the OTA update process, which is able to correct software failures due to the update.

[55] Figure 2A depicts how an OTA update monitor is implemented for the first processor 102 and the second processor 104. The first processor 102 comprises a first update monitor 112 (or first OTA update monitor) and the second processor 104 comprises a second update monitor 122 (or second OTA update monitor). The function of the OTA update monitor 112, located and running on the first processor 102, is to monitor the OTA software update on the second processor 104. The function of the OTA update monitor 122, located and running on the second processor 104, is to monitor the OTA software update on the first processor 102. When a failure is detected on the second processor 104 (i.e., an OTA software update is unsuccessful or the new OTA software update is flawed), the OTA update monitor 112 on the first processor 102 will trigger a rollback mechanism 114, located and running on the first processor 102, to revert the updated software on the second processor 104 to a previous version of software that is known to work. Likewise, when a failure is detected on the first processor 102, the OTA update monitor 122 will trigger a rollback mechanism 124, located and running on the second processor 104, to revert the updated software on the first processor 102 to a previous version of software that is known to work.

[56] As will be discussed in greater detail below, the OTA update monitor 112 on the first processor 102 may instead trigger a rollback mechanism 124 located and running on the second processor 14 to revert the updated software on the second processor 104 to a previous version of software that is known to work. Additionally, the OTA update monitor 122 of the second processor 104 may likewise initiate a similar, inverse response after detecting a software update failure on the first processor 102. The disclosed procedure advantageously allows for a first component (e.g., update monitor 112) to monitor software of a second component (e.g., update monitor 122) and to “roll back” or reintroduce working software onto the second component using the rollback procedure in the event of an update failure on the second component. In other words, the first component is arranged to (1) detect a failure in the second component, (2) “roll back” the second component using the rollback procedure, and then roll back (i.e., either by itself or by the second component) using a subsequent rollback procedure to restore the same working software onto the first component.

[57] To monitor the update of a processor 102, 104, the update monitor 112, 122 must be able to communicate with the other processor 104, 102, respectively. As depicted in Figure 2A, the first processor 102 and the second processor 104 are connected via an inter-system communication (ISC) channel 106. First and second processors 102, 104 notify each other of their software update status via the ISC channel 106. The OTA update monitors 112, 122 check the ISC channel 106 for status updates during and after the OTA software updates. A software update failure in an updated processor 102, 104 will cause that same processor to send abnormal status updates, or no updates at all, to the other processor 104, 102. This will be detected by the receiving OTA update monitor 122, 112, which will then conclude that the update failed.

[58] In order to respond to a software update failure, a “processor update mode” is defined to activate the processor to be updated in a preparatory state to receive the new software. Before the OTA software update begins, the initial processor to be updated, e.g., second processor 104, is put into an update mode. Next, the installation of the OTA software update for that second processor 104 is performed while the first processor 102 monitors the software update process. After the OTA software update is complete, the updated second processor 104 remains in the update mode while the OTA update monitor 112 on the first processor 102 verifies the state of the second processor 104 by checking the ISC channel 106 for status updates. If the status updates via ISC channel 106 to the first processor 102 indicate that the OTA software update of the second processor 104 was successful, the second processor 104 is permitted to exit from the update mode. In this case, for example, the OTA update monitor 112 will use the ISC channel 106 to signal that the software update was successful by sending a confirmation message (e.g., “OTA update successful”) via the ISC channel 106 to the second processor 104. This will cause the second processor 104 to exit from update mode. If the update fails or the updated software is not working correctly, the update mode of the second processor 104 is not deactivated and the second processor 104 is subsequently reset (i.e., via reset line 108) by the first processor 102, which will cause the second processor 104 to reboot. When the reset and reboot is performed while the second processor 104 is still in update mode, a rollback mechanism 114 (or rollback mechanism 124) will be automatically triggered to recover a previously installed version of the software.

[59] To enable the reset of the second processor 104 by the OTA update monitor 112 on the other processor 102, low-level hardware connections or reset lines 108, 110 are implemented between the first processor 102 and the second processor 104. These reset lines 108, 110 are configured to operate on a hardware reset circuitry that is typically available both in MCUs and MPUs. Thus, a processor 104 can advantageously be reset even when the software on that processor 104 does not work anymore. This is crucial, as the OTA update procedure may lead to software failure. The reset lines 108, 110 differ from the ISC channel 106 in this regard; the ISC channel 106 is dependent on the installed, updated software to work correctly. The ISC channel 106 is preferably not to be used to reset the updated processor 104. This preferred embodiment guarantees the capability of resetting the processors 102, 104 via the reset lines 108, 110. The reset lines 108, 110 operate on hardware reset circuitry independent from the ISC channel 106 between the first processor 102 and the second processor 104 and are dependent on successful completion of the over-the-air software update. In an embodiment, the reset lines 108, 110 may be configured as one reset channel connecting the first processor 102 and the second processor 104. One skilled in the art will recognize that the ISC channel may be used to reset the processors 102, 104. However, it is possible that the updated processor 104 may not be responsive after an OTA update, meaning that the processor 104 may not act on data and commands that are sent via the ISC channel 106.

[60] The update mode status (e.g., enabled / disabled) for each processor 102, 104 is stored in computer storage media 116, 126 that is operatively coupled to each processing unit. Thus, a reset and reboot will not change the mode of the processor. A processor 102, 104 in an update mode remains in the update mode after reset and reboot. This feature allows the rollback mechanism 114, 124, respectively, which is activated upon reset and reboot to perform a rollback evaluation procedure, to identify that the reset occurred in the context of a failed software update, if a reset happens while the update mode is still active for a given process.

[61] A rollback mechanism is implemented on both processors 102, 104 to recover the previously installed version of software in case the updated software fails to work. The first processor 102 comprises a primary or first rollback mechanism 114, the second processor comprises a secondary or second rollback mechanism 124. The terms primary and secondary are used to describe separate and distinct rollback mechanisms being installed on separate and distinct processors. The rollback mechanism 114, 124 initiates a rollback evaluation procedure each time a processor 102, 104 is started or restarted, meaning that each rollback mechanism 114, 124 is started after a reset and reboot trigged by the OTA update monitor 112, 122 in case of a failed update on for the respective processor 102, 104, as described above. However, the rollback mechanism 114, 124 for each processor 102, 104 will also initiate a rollback evaluation procedure when the processor 102, 104 (or entire dual component system 101 or controller 103) is started / rebooted under “normal” circumstances (i.e., not in the context of a software update, e.g., due to a power cycle of machine or controller 103). The first task of the rollback mechanism 114, 124 is therefore, using the evaluation procedure, to determine whether the startup (also referred to as boot) of the processor 102, 104 is occurring due to a reset following a failed OTA update, or whether the startup is a normal startup. A rollback mechanism 114, 124 triggers a rollback operation in the event of a failed software update; the rollback operation of a rollback mechanism 114, 124 should not be triggered in the event of a normal startup. The evaluation procedure of the rollback mechanism 114, 124 relies on the update mode status of the respective processor 102, 104, which can be retrieved from the computer storage media 116, 126. If an update mode is active for a processor 102, 104 during the reboot of the processor, the reboot will be triggered by the OTA update monitor 112, 122 following a failed software update. In that case, the rollback mechanism 114, 124 will restore or reinstate the previous version of the software to the processor 102, 104 by prompting the processor 102, 104 to reinstall a previous version of software stored on the computer storage media 116, 126. If the processor 102, 104 is not in update mode, the rollback mechanism 114, 124 will not take action (i.e., the rollback operation will not be triggered) and the processor boot up will be considered as a normal boot.

[62] In an embodiment, the rollback mechanism 114 is located and runs on the first processor 102 and functions to restore a previous version of software, stored in the computer storage media 116 of the first processor 102, onto the first processor 102. The OTA update monitor 122 of the second processor 104 monitors the restoration of the previous software back onto the first processor 102. In an alternative embodiment, the rollback mechanism 114, locating and running on the first processor 102, functions to restore a previous version of software that is stored in the computer storage media 126 of the second processor 104, back onto the second processor 104. In this alternative embodiment, the OTA update monitor 112 of the first processor 102 monitors the restoration of the previous software back onto the second processor 104.

[63] It is possible that a processor 102, 104 is rebooted one or multiple times as part of the OTA update procedure. For example, it is possible that the OTA update involves writing the new software to the computer storage media 116, 126 and then restarting the processor 102, 104 to switch to the new software. In this case, the processor 102, 104 will be restarted and rebooted while still in an update mode. The update mode being “active” does not mean the update has failed in this case. The disclosed solutions may implement a boot counter as part of the rollback mechanism 114, 124. This boot counter, which is stored in the computer storage media 116, 126, is augmented every time the processor 102, 104 is rebooted. The rollback mechanism 114, 124 will only trigger a rollback operation when the boot count is higher than expected from a normal OTA update. For example, if one single reboot of the processor 102, 104 while in update mode is expected during a normal OTA update, the rollback mechanism 114, 124 will only trigger a rollback operation when the boot counter equals 2 and the processor 102, 104 is still in update mode. Upon exiting of update mode (after successful verification of the new software), the boot counter for the processor 102, 104 is reset to 0.

[64] For the rollback mechanism 114, 124 to restore a previous version of software to the processor 102, 104 using a rollback operation, the previous version of software is available on the computer storage media 116, 126 of each processor 102, 104. In an embodiment, whenever a new software version is installed through an OTA update, the old version is not removed but kept available in a dedicated backup slot communicatively connected to integrated with the computer storage media 116, 126. In an embodiment, a penultimate version, an antepenultimate version, and even older version(s) of the software may be stored in the computer storage media 116, 126 for redundancy and ensuring access to previous working version of the software.

[65] Figure 2B depicts an alternative configuration for how the dual component system 101 may be implemented with the first processor 102 and the second processor 104. In this embodiment, the dual component system 101 includes a service 117 being communicatively coupled to both the first processor 102 and the second processor 104. The service 117 performs both operations of the ISC channel 106 and reset lines 108, 110 in the embodiment described with Figure 2A. In some cases, the service 117 can be a deterministic service that operates fully given a set of inputs and without a randomization factor. In other cases, service 117 can be or can include a machine learning (ML) or artificial intelligence engine to enable the service 117 to operate even when faced with a randomization factor.

[66] In some implementations, the service 117 is a cloud service operating in a cloud environment. In some implementations, the service 117 is a local service operating on a local device, such as the ER system. In some implementations, the service 117 is a hybrid service that includes a cloud component operating in the cloud and a local component operating on a local device. These two components can communicate with one another. The service 117 is generally tasked with operatively connecting the first processor 102 with the second processor 104. In an embodiment, the service 117 functions as a proxy server or intermediary between the first processor 102 and the second processor 104. In an alternative embodiment, the service 117 functions as a virtual machine. The service 117 may receive incoming data, i.e., software update, from a network 107, server 111, or directly from a software origination device 109.

[67] Figure 3 illustrates a flowchart of the disclosed software update process. As discussed, a complicating factor for performing an OTA software update is that an OTA software update may fail for one of the two processors 102, 104, but not for the other, which leads to a rollback operation of the rollback mechanism 114, 124 being triggered only on one processor 102, 104. As a result, one processor 102, 104 will be running a newer software version than the other processor 104, 102. This is problematic, as software versions need to be aligned for correct operation. “Aligned” software means that the versions of software are the same (i.e., identical) or correspond to one another. The dual component system 101 prevents the processors 102, 104 from simultaneously running different software for the controller 103. It is possible that new features available in the new software of the first processor 102 expect new software running on the second processor 104. Examples of the new features may include bugfixes and security updates in general, new views for the communication interface (e.g., HMI display), improved control logic leading to a more efficient (e.g., less energy-consuming) operation of the tool, extension of the Bluetooth connection interface, allowing for aspects or settings to be controlled remotely mobile app, and extension of the data upload, or uploading additional data to the service 117 or cloud. The new software on the first processor 102 may thus be incompatible with the old software on the second processor 104. For this reason, if a rollback mechanism 114, 124 is triggered and rollback operation performed for one processor 102, 104 while the other processor 104, 102 was successfully updated, a rollback mechanism 124, 114 is also triggered for the latter processor 104, 102. Figure 3 outlines how this process is executed.

[68] Figure 3 covers various scenarios regarding the OTA software update for a dual component system (e.g., 101). For example, Figure 3 considers a scenario where an OTA software update of PU A is successful while the subsequent update of PU B is not. After a rollback is triggered for PU B, a rollback is retroactively triggered for PU A as well. In this case, it is the responsibility of the OTA update monitor of PU A to trigger the rollback of PU A after triggering the rollback of PU B.

[69] As mentioned above, the functional verification of new features added via the OTA update requires that the component managing the update to be updated as well. If this would not be the case, newly added features are unable to be verified because the verification code is static and will not be alerted of the new features. In Figure 3, PU A is updated first and monitored by PU B. After the update of PU A, it is PU B that will verify PU A to decide whether PU A is still functional after the update. However, at this point in the flow, PU B is prevented from verifying new functionality of PU A in a smart way because PU B is not yet updated. As such, the component of PU B managing the update verification is not yet aware of the new features of PU A.

[70] To address this issue, an additional functional verification stage is introduced after the verification of PU B by PU A. Thus, the following steps are provided:Update of PU A while PU B is monitoring the update;Basic verification of PU A by PU B after update of PU A: are the basic functions of PU A still working? These are functions that do not change via an update. New features cannot be verified at this point because PU B has not yet been updated so the OTA managing component of PU B is not yet aware of the new features of PU A;Update of PU B while PU A is monitoring the update;Complete “smart” verification of PU B by PU A: now the situation is different because PU A is already updated and has knowledge of new features of PU B added via the update of PU B and can thus verify these features; andAdditional “smart” verification of PU A by PU B: at this point, PU B is updated and can perform a verification of the new features of PU A added via the update of PU A.

[71] It is possible for PU B to reset PU A even after the update of PU B. How this can be done depends on whether PU A is kept in update mode until after the update of PU B. There are two options: (1) after updating PU A, PU A remains in update mode until after the update of PU B because the update of the complete system is not yet finished; thus, a reset of PU A after the update of PU B will trigger a rollback of PU A, or (2) after updating PU A and before updating PU B, PU A exits update mode; thus, a reset of PU A after the update of PU B will not trigger a rollback operation. Either option can result in the update of PU B. Option (1) is a preferred method to keep both PUs in update mode until all verification is complete and to easily trigger a rollback of either PU, i.e., by simply resetting that PU.

[72] In an embodiment, the last verification step may trigger a rollback of both PU B and PU A. If PU B carries out the last verification step, then PU B will initiate the rollback mechanism. Under option (1), PU B may initiate the rollback of PU A via a simple reset. And PU B can trigger its own rollback by simply resetting itself. Under option (2), a simple reset of PU A after the update of PU B will not trigger the rollback mechanism of PU A. In this case, PU A will have to be rolled back by PU B sending a command on the ISC channel (e.g., 106) to PU A, and PU A starting the rollback of PU A. This can be as simple as PU A re-enabling the update mode on itself and subsequently resetting itself. This will cause the rollback evaluation mechanism of PU A to start and, because of the update mode being active, lead to a rollback of previous software being restored on PU A. Likewise, PU B can rollback itself by first re-enabling update mode and subsequently resetting itself.

[73] Regarding the rollback of the old, previous version of software on PU A, PU B may have to trigger the rollback of PU A. In case the aforementioned option (1) is used, triggering the rollback of PU A is as simple as resetting PU A. The reset action can be executed from the higher-level software (that is, the software that is being updated) of PU B, but it is also possible for the rollback mechanism of PU B to reset PU A, thereby triggering the rollback of PU A. Thus, it is possible for the rollback mechanism of a given PU to also trigger the rollback on the other PU. However, instead of the given PU executing the rollback operation of the other PU, the other PU is reset while that PU is still in update mode. When a reset occurs when a PU is in update mode, preferably, it is the rollback mechanism of the other PU that carries out the rollback of that other PU. In other words, in a preferred embodiment, the rollback mechanism of a given PU has no direct control over the rollback mechanism of the other PU other than resetting the other PU, thereby triggering the rollback evaluation process of that other PU. As outlined above, in case of the complex situation of option (2), the ISC command channel will have to be used by PU B to roll back PU A.

[74] In an embodiment, the functional verification preferably includes both basic verification of existing and un-updated functionalities of a PU and smart verification of new functionalities provided by the OTA update. Preferably, the computer system performs a basic verification on a PU A by the PU B after the PU A has implemented the OTA software update and ensures that basic functions of the PU A are unaffected. The computer system also performs a smart verification on the PU B by the PU A after the PU B has implemented the OTA software update and ensure that new functionalities are present and operable on the PU B. The computer system may also perform a subsequent smart verification on the PU A by the PU B following the smart verification of the PU B and ensure that new functionalities are present and operable on the PU A.

[75] In the event that the subsequent smart verification fails to ensure that new functionalities are present and operable on the PU A, the PU B triggers the rollback of PU A to reinstate a previous version of software on the PU A and, subsequently, the PU B triggers its own rollback mechanism to reinstate the previous version of software on the PU B. In an alternative embodiment, following an unsuccessful update of PU B or attempt of the subsequent smart verification by PU A, the PU A triggers the rollback of PU B to reinstate a previous version of software on the PU B and, subsequently, the PU A triggers its own rollback mechanism to reinstate the previous version of software on the PU A. Thus, a rollback operation is performed on both PUs to ensure software alignment between PUs.

[76] It should be noted that the piece of software implementing the rollback mechanism 114, 124 is stored in a dedicated part of the processor 102, 104 (i.e., computer storage media 116, 126), preferably marked as read-only. This means that this software is not part of the OTA software update, i.e., it is not “updatable”. During an OTA software update, the updatable software is replaced by a newer version that is not guaranteed to work. Because updatable software can fail due to an improper update, it is possible to rely on the rollback mechanism 114, 124 to roll back the updatable software to the previous version on the processor 102, 104. As such, the rollback mechanism 114, 124 (i.e., being a separate software) is excluded and cannot be part of the updatable software because an improper OTA update could alter the functionality of the rollback mechanism in that case, preventing the automatic recovery of the previous software version.

[77] The disclosed dual component system 101 executes a functional verification of new features added via the software update. The dual component system 101, comprising first and second processors 102, 104 (one processor for managing the update and the other processor being updated by the managing processor), and both processors are updated by the software update system 100. The requirement for alignment of the software installed on both processors 102, 104, i.e., checking the status of the software update to confirm uniformity of software, thus leads to the disclosed rollback mechanism 114, 124 being performed of one processor 102, 104, and subsequent rollback mechanism 124, 114 being performed of the other processor 104, 102.

[78] Embodiments of the disclosure may comprise or utilize a special-purpose or general-purpose computer system (e.g., software update system 100) that includes computer hardware, such as, for example, a dual component system 101 (e.g., comprising first and second processors 102, 104) and system memory and storage (e.g., computer storage media 116, 126), as discussed in greater detail above. Embodiments within the scope of the present disclosure include physical and other computer-readable media for carrying or storing computer-executable instructions and / or data structures. Such computer-readable media can be any available media that can be accessed by a general-purpose or special-purpose computer system. Computer-readable media that store computer-executable instructions and / or data structures are computer storage media 116, 126. Computer-readable media that carry computer-executable instructions and / or data structures are transmission media. Thus, by way of example, embodiments of the disclosure can comprise at least two different kinds of computer-readable media: computer storage media and transmission media.

[79] Computer storage media are physical storage media that store computer-executable instructions and / or data structures. Physical storage media include computer hardware, such as random access memory (RAM), read-only memory (ROM), electrically erasable programmable ROM (EEPROM), solid state drives (SSDs), flash memory, phase-change memory (PCM), optical disk storage, magnetic disk storage or other magnetic storage devices, or any other hardware storage device(s) which can be used to store program code in the form of computer-executable instructions or data structures, which can be accessed and executed by a general-purpose or special-purpose computer system to implement the disclosed functionality.

[80] Transmission media can include a network and / or data links which can be used to carry program code in the form of computer-executable instructions or data structures, and which can be accessed by a general-purpose or special-purpose computer system. A “network” is defined as one or more data links that enable the transport of electronic data between computer systems and / or modules and / or other electronic devices. When information is transferred or provided over a network or another communications connection (either hardwired, wireless, or a combination of hardwired or wireless) to a computer system, the computer system may view the connection as transmission media. Combinations of the above should also be included within the scope of computer-readable media. Further, upon reaching various computer system components, program code in the form of computer-executable instructions or data structures can be transferred automatically from transmission media to computer storage media (or vice versa). It should be understood that computer storage media can be included in computer system components that also (or even primarily) utilize transmission media.

[81] Computer-executable instructions comprise, for example, instructions and data which, when executed at one or more processors, cause a general-purpose computer system, special-purpose computer system, or special-purpose processing device to perform a certain function or group of functions. Computer-executable instructions may be, for example, binaries, intermediate format instructions such as assembly language, or even source code.

[82] It will be appreciated that the disclosed systems and methods may be practiced in network computing environments with many types of computer system configurations, including, personal computers, desktop computers, laptop computers, message processors, hand-held devices, multi-processor systems, microprocessor-based or programmable consumer electronics, network PCs, minicomputers, mainframe computers, mobile telephones, PDAs, tablets, pagers, routers, switches, and the like. Embodiments of the disclosure may also be practiced in distributed system environments where local and remote computer systems, which are linked (either by hardwired data links, wireless data links, or by a combination of hardwired and wireless data links) through a network, both perform tasks. As such, in a distributed system environment, a computer system may include a plurality of constituent computer systems. In a distributed system environment, program modules may be located in both local and remote memory storage devices.

[83] It will also be appreciated that the embodiments of the disclosure may be practiced in a cloud computing environment. Cloud computing environments may be distributed, although this is not required. When distributed, cloud computing environments may be distributed internationally within an organization and / or have components possessed across multiple organizations. In this description and the following claims, “cloud computing” is defined as a model for enabling on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services). A cloud computing model can be composed of various characteristics, such as on-demand self-service, broad network access, resource pooling, rapid elasticity, measured service, and so forth. A cloud computing model may also come in the form of various service models such as, for example, Software as a Service (SaaS), Platform as a Service (PaaS), and Infrastructure as a Service (IaaS). The cloud computing model may also be deployed using different deployment models such as private cloud, community cloud, public cloud, hybrid cloud, and so forth.

[84] Although the subject matter has been described in language specific to structural features and / or methodological acts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the described features or acts described above, or the order of the acts described above. Rather, the described features and acts are disclosed as example forms of implementing the claims.

[85] The present disclosure may be embodied in other specific forms without departing from its essential characteristics. Such embodiments may include a data processing device comprising means for carrying out one or more of the methods described herein; a computer program comprising instructions which, when the program is executed by a computer, cause the computer to carry out one or more of the methods described herein; and / or a computer-readable medium comprising instructions which, when executed by a computer, cause the computer to carry out one or more of the methods described herein. The described embodiments are to be considered in all respects only as illustrative and not restrictive. All changes which come within the meaning and range of equivalency of the claims are to be embraced within their scope.

[86] It will be understood that, although the terms first, second, etc. may be used herein to describe various elements, these elements should not be limited by these terms. These terms are only used to distinguish one element from another. For example, a first element could be termed a second element, and, similarly, a second element could be termed a first element, without departing from the scope of the present invention. As used herein, the term “and / or” includes any and all combinations of one or more of the associated listed items. It is further understood that the use of relational terms such as first and second, and the like are used solely to distinguish one entity from another without necessarily requiring or implying any actual such relationship or order between such entities.

[87] It is to be understood that even though numerous characteristics and advantages of various embodiments of the present disclosure have been set forth in the foregoing description, together with details of the structure and function of various embodiments thereof, this detailed description is illustrative only, and changes may be made in detail, especially in matters of structure and arrangements of parts within the principles of the present disclosure to the full extent indicated by the broad general meaning of the terms in which the appended claims are expressed.

Claims

1. A computer system comprising: a first processor; a second processor; and one or more hardware storage devices that store instructions that are executable to cause the computer system to: access a software update that is structured to be executable by the first processor and the second processor; while preventing the second processor from implementing the software update, cause the first processor to implement the software update; while the first processor is implementing the software update, monitor the first processor to ensure that the first processor successfully implements the software update; after determining that the first processor has successfully implemented the software update, cause the second processor to begin to implement the software update; while the second processor is implementing the software update, monitor the second processor to ensure that the second processor successfully implements the software update.

2. A computer system comprising: a first processor; a second processor; and one or more hardware storage devices that store instructions that are executable to cause the computer system to: access a software update that is structured to be executable by the first processor and the second processor; while preventing the second processor from implementing the software update, cause the first processor to implement the software update; while the first processor is implementing the software update, monitor the first processor to ensure whether the first processor successfully implements the software update; after determining that the first processor has unsuccessfully implemented the software update, cause the first processor to trigger a rollback mechanism to reinstate a previous version of software while still preventing the second processor from implementing the software update.

3. A computer system comprising: a first processor; a second processor; and one or more hardware storage devices that store instructions that are executable to cause the computer system to: access a software update that is structured to be executable by the first processor and the second processor; while preventing the second processor from implementing the software update, cause the first processor to implement the software update; while the first processor is implementing the software update, monitor the first processor to ensure that the first processor successfully implements the software update; after determining that the first processor has successfully implemented the software update, cause the second processor to begin to implement the software update; while the second processor is implementing the software update, monitor the second processor to ensure whether the second processor successfully implements the software update; after determining that the second processor has unsuccessfully implemented the software update, cause the second processor to trigger a rollback mechanism to reinstate a previous version of software on the second processor; after reinstating the previous version of software on the second processor, cause the first processor to trigger another rollback mechanism to reinstate the previous version of software on the first processor.

4. A dual component system for updating software comprising: a first processing unit; a second processing unit, a first computer storage media operatively coupled to the first processing unit; and a second computer storage media operatively coupled to the second processing unit; wherein the first computer storage media stores computer-executable instructions that are executable by the first processing unit to at least: monitor an over-the-air software update on the second processing unit; detect failures occurring in the over-the-air software update on the second processing unit; trigger a primary rollback mechanism upon detection of installation failure occurring in the over-the-air software update on the first processing unit; and reset the over-the-air software update on the second processing unit to a previously installed software on the second processing unit using a reset channel; wherein the second computer storage media stores computer-executable instructions that are executable by the second processing unit to at least: monitor the over-the-air software update on the first processing unit; detect failures occurring in the over-the-air software update on the first processing unit; trigger a secondary rollback mechanism upon detection of installation failure occurring in the over-the-air software update on the second processing unit; and reset the over-the-air software update on the first processing unit to the previously installed software on the first processing unit using the reset channel; wherein the over-the-air software update for the first processing unit is performed separately from the over-the-air software update for the second processing unit.

5. The dual component system of claim 4, wherein the first processing unit and the second processing unit are embedded in a controller.

6. The dual component system of claim 4, wherein the computer-executable instructions are further executable by the first processing unit to at least notify the second processing unit via an inter-system communication channel between the first processing unit and the second processing unit of status updates concerning the over-the-air software update.

7. The dual component system of claim 4, wherein the computer-executable instructions are further executable by the first processing unit to at least perform a functional verification of new functionalities installed on the second processing unit by the over-the-air software update.

8. The dual component system of claim 7, wherein the computer-executable instructions are further executable by the second processing unit to place the second processing unit into an update mode during the over-the-air software update.

9. The dual component system of claim 8, wherein the second processing unit remains in the update mode during the functional verification of the new functionalities installed on the second processing unit by the over-the-air software update.

10. The dual component system of claim 9, wherein the computer-executable instructions are further executable by the first processing unit to remove the second processing unit from the update mode upon receiving via an inter-system communication channel between the first processing unit and the second processing unit of a status update indicating successful completion of the over-the-air software update.

11. The dual component system of claim 10, wherein the primary rollback mechanism is dependent on status of the update mode of the second processing unit, the status being retrieved from the second computer storage media via the inter-system communication channel.

12. The dual component system of claim 4, wherein the reset channel operates on hardware reset circuitry independent from an inter-system communication channel between the first processing unit and the second processing unit and is dependent on successful completion of the over-the-air software update.

13. The dual component system of claim 4, wherein the primary rollback mechanism is prepared upon startup or restarting of the second processing unit.

14. The dual component system of claim 4, wherein the computer-executable instructions are further executable by the first processing unit to register whether startup of the first processing unit occurs due to a reset after failure occurring in the over-the-air software update on the second processing unit or whether the startup of the first processing unit is under normal conditions.

15. The dual component system of claim 14, wherein the computer-executable instructions are further executable by the second processing unit to trigger the primary rollback mechanism in response to the trigger of the secondary rollback mechanism upon detection of installation failure occurring in the over-the-air software update on the first processing unit.

16. The dual component system of claim 15, wherein software installed on the first processing unit is aligned with software installed on the second processing unit after triggering of both the primary rollback mechanism and the secondary rollback mechanism.

17. The dual component system of claim 15, wherein the secondary rollback mechanism is excluded from the over-the-air software update on the first processing unit and the primary rollback mechanism is excluded from the over-the-air software update on the second processing unit.

18. A method for updating software, implemented at a controller embedded with a first processing unit and a second processing unit, the method comprising: monitoring an over-the-air software update on the second processing unit with the first processing unit; detecting failures occurring in the over-the-air software update on the second processing unit via an inter-system communication channel connecting the first processing unit to the second processing unit; triggering a primary rollback mechanism installed on the second processing unit upon detection of installation failure occurring in the over-the-air software update on the second processing unit; and reverting the over-the-air software update on the second processing unit to previously installed software on the second processing unit using a reset channel.

19. The method according to claim 18 further comprising: monitoring a subsequent over-the-air software update on the first processing unit with the second processing unit; detecting failures occurring in the subsequent over-the-air software update on the first processing unit via the inter-system communication channel; trigger a secondary rollback mechanism installed on the first processing unit upon detection of installation failure occurring in the subsequent over-the-air software update on the first processing unit; and reverting the over-the-air software update on the first processing unit to previously installed software on the first processing unit using the reset channel.

20. The method according to claim 19 further comprising: performing a functional verification test of new functionalities installed on the second processing unit by the over-the-air software update.

21. The method according to claim 19 further comprising: placing the second processing unit into an update mode during the over-the-air software update; and removing the second processing unit from the update mode upon receiving via the inter-system communication channel of a status update indicating successful completion of the over-the-air software update.

22. The method according to claim 19 further comprising: aligning software installed on the second processing unit with software installed on the first processing unit after triggering of both the primary rollback mechanism and the secondary rollback mechanism, the software installed on the first processing unit being identical to the software installed on the second processing unit.

23. The method according to claim 19, wherein the secondary rollback mechanism is excluded from the over-the-air software update on the first processing unit and the primary rollback mechanism is excluded from the subsequent over-the-air software update on the second processing unit.

24. The computer system according to claim 1, wherein the instructions are further executable to cause the computer system to perform a basic verification of the first processor by the second processor after the first processor has implemented the software update and ensure that basic functions of the first processor are unaffected.

25. The computer system according to claim 24, wherein the instructions are further executable to cause the computer system to perform a smart verification of the second processor by the first processor after the second processor has implemented the software update and ensure that new functionalities are present and operable on the second processor.

26. The computer system according to claim 25, wherein the instructions are further executable to cause the computer system to perform a subsequent smart verification of the first processor by the second processor following the smart verification of the second processor and ensure that new functionalities are present and operable on the first processor.

27. The computer system according to claim 26, wherein the instructions are further executable to cause the computer system to perform, in response to a determination that the subsequent smart verification fails to ensure that new functionalities are present and operable on the first processor, cause the second processor to trigger a first rollback mechanism to reinstate a previous version of software on the second processor and subsequently cause the first processor to trigger a second rollback mechanism to reinstate the previous version of software on the first processor. 

Images