BACKGROUND

Modern vehicles utilize many Electronic Control Units (ECUs) to control operations of components such as engines, powertrains, transmissions, brakes, suspensions, onboard entertainment systems, communication systems, and the like. ECUs control basic operations of modern vehicles, from power steering to breaking to acceleration. In addition ECUs control numerous add-on and analytical features in vehicles. For example, some cars may be equipped with ECUs configured to collect and analyze driving data, which may be provided to insurance companies to determine insurance premiums. Some cars may be equipped with ECUs configured to enhance the driving experience, and some may be equipped with ECUs configured to provide advanced (or automated) driving assistance.

As ECUs continue to increase in complexity and sophistication, managing software performance, upgrades, and bug fixes on ECUs is becoming a challenge. Currently, there are roughly 60 to 70 ECUs in an average car (and roughly 180 ECUs in a luxury car). These ECUs correspond to tens of millions of lines of code. Maintaining the code is becoming increasingly difficult. Moreover, highly sophisticated software tends to be more prone to vulnerabilities such as software bugs, glitches and calibration problems. Manufacturers or developers of ECUs may wish to promptly fix these vulnerabilities as soon as they are discovered.

A further type of vulnerability in ECUs relates to ECU errors or faults. An ECU error may be, for example, a runtime error, stack overflow, stack underflow, etc. An ECU fault may be, for example, a deviation ire the normal or expected operation of an ECU (e.g., performing a function a certain number of times per time interval, but then “drifting” to perform the function a different number of times, either suddenly or slowly over time). Slowly implemented drifting in the execution of ECU software can be a particularly difficult problem, since it is hard to immediately detect given the lack of any obvious signs of changes to the ECU's operation.

One approach to address these vulnerabilities in affected vehicles is to issue a recall. However, recalls can be time-consuming, and they do not provide any assurance that the affected vehicles will be fixed in a timely manner. Alternatively, manufacturers or developers may attempt to provide fixes to the affected vehicles through on-board diagnostic (OBD) ports or over-the-air (e.g., using various types of wireless communication techniques). Nevertheless, OBD ports are themselves attack surfaces for vehicles, and over-the-air fixes are typically inefficient, inconvenient to the vehicle owner, and prone to introduce yet additional bugs.

Moreover, current attempts of OBD and over-the-air update techniques still have limitations in terms of time and space efficiency. For example, current attempts of over-the-air-update techniques require the manufacturer to distribute a new version of the entire ECU software as a replacement package to the affected vehicles. When the replacement package is received by an affected vehicle, the affected vehicle is required to store the replacement package into a spare memory space (i.e., a memory space not used by the ECU), erase the current version of the ECU software from the memory space used by the ECU, copy the replacement package from the spare memory space into the memory space used by the ECU, and restart the ECU so it can load the new version of the ECU software. This is virtually impossible in ECUs, due to significant storage space limitations and the interruption to the functioning of the ECU. ECUs are nearly full with existing software and data already, and have very limited available storage space for new software or data. Further, there are significant cost limitations associated with providing new software to ECUs. Moreover, interrupting the processing flow of an ECU can be inconvenient or very dangerous, depending on the role of the ECU and the conditions of the vehicle.

There is thus a need for technological solutions to generate, receive, and process update packages for updating software on ECUs without the aforementioned shortcomings. In particular, there is a need for solutions for updating a vehicle with differential software, rather than an entire software module or package, over the air and without a dedicated client on an ECU. Further, solutions should not have a requirement of significant additional memory usage, or any downtime of the ECU itself. In addition, such solutions should not require reprogramming the memory of the ECU. Further, such solutions should allow for rolling back the software version on an ECU to a prior version without the need to download an entire software module, without reprogramming the memory (which can be expensive, time-consuming, and disruptive), and again without significant memory requirements or any downtime of the ECU.

There is also a need for technological solutions to generate data for abnormality detection that will not consume large amounts of data throughput to store or to transmit. Such techniques should provide lean execution performance to keep the main application on an ECU running, with all its resources it needs, and without additional required resources. It would further be advantageous to utilize a distributed vehicle architecture solution that sends only calls for action (e.g., based on anomaly detection through machine learning) to a control center or server for performing responsive actions.

Further, there is a need for technological solutions for the problems that arise based on dependencies between ECUs in vehicles. For example, when the software on one ECU is updated, it may cause the ECU to be unable to communicate with other ECUs in the vehicle. This may occur, for example, when the update to the ECU affects its network address, incoming or outgoing communications policies, format or payload of data communications, timing of communications, protocol of communications, or various other attributes of its functionality. It would be advantageous, therefore, to be able to manage the dependencies between ECUs so that software updates to ECUs can be coordinated and performed on all ECUs that may be impacted by an update.

SUMMARY

The disclosed embodiments describe non-transitory computer readable media and methods for opportunistically updating Electronic Control Unit (ECU) software in a vehicle. For example, in an exemplary embodiment, there may be a non-transitory computer readable medium including instructions that, when executed by at least one processor, cause the at least one processor to perform operations for opportunistically updating Electronic Control Unit (ECU) software in a vehicle. The operations may comprise receiving, at a controller in a vehicle, a wireless transmission indicating a need to update software running on at least one ECU in the vehicle; monitoring an operational status of the vehicle to determine whether the vehicle is in a first mode of operation in which an ECU software update is prohibited; delaying the ECU software update when the operational status is prohibited; continuing to monitor the operational status of the vehicle to determine whether the vehicle is in a second mode of operation in which the ECU software update is permitted; and enabling updating of the at least one ECU with the delayed ECU software update when it is determined that the vehicle is in the second mode of operation.

According to a disclosed embodiment, continuing to monitor the operational status of the vehicle comprises repeatedly monitoring the operational status of the vehicle according to a preestablished interval.

According to a disclosed embodiment, the instructions further comprise: storing the ECU software update in a memory located on the vehicle for delayed update when the vehicle is in the first mode of operation.

According to a disclosed embodiment, the delayed software update is maintained on a server remote from the vehicle when the vehicle is in the first mode of operation, and the instructions may further comprise: sending a message to the remote server when the vehicle is in the second mode of operation; receiving the ECU software update in reply to the message; and installing the ECU software update on the at least one ECU in the vehicle when the vehicle is in the second mode of operation.

According to a disclosed embodiment, the second mode of operation comprises one of a plurality of predetermined safe operating conditions.

According to a disclosed embodiment, the second mode of operation comprises a power-down status of the vehicle.

According to a disclosed embodiment, the second mode of operation comprises an idling status of the vehicle.

According to a disclosed embodiment the second mode of operation comprises a period of wireless communications strength above a threshold of strength.

According to a disclosed embodiment, the second mode of operation comprises a preselected environmental condition of the vehicle.

According to a disclosed embodiment, the second mode of operation comprises a network connection with an error rate below a threshold.

According to a disclosed embodiment, the wireless transmission indicating the need to update the software comprises an indication of whether the update is with or without an override status.

According to a disclosed embodiment, the instructions further comprise: updating the ECU software regardless of whether the vehicle is its the first mode of operation when the update is received with the override status.

According to a disclosed embodiment, the ECU software is mapped to a plurality of functional units, and the ECU is configured to utilize a virtual file system (VFS) to manage and track one or more versions of each of the plurality of functional units.

According to a disclosed embodiment, a system may be implemented for opportunistically updating ECU software in a vehicle. The system may comprise: one or more processors; and one or more memories having instructions that, when executed by the one or more processors, cause the one or more processors to perform the operations of: receiving, at a controller in a vehicle, a wireless transmission indicating a need to update software running on at least one ECU in the vehicle; monitoring an operational status of the vehicle to determine whether the vehicle is in a first mode of operation in which an ECU software update is prohibited; delaying the ECU software update when the operational status is prohibited; continuing to monitor the operational status of the vehicle to determine whether the vehicle is in a second mode of operation in which the ECU software update is permitted; and enabling updating of the at least one ECU with the delayed ECU software update when it is determined that the vehicle is in the second mode of operation.

According to a disclosed embodiment, continuing to monitor the operational status of the vehicle comprises repeatedly monitoring the operational status of the vehicle according to a preestablished interval.

According to a disclosed embodiment, the wireless transmission indicating the need to update the software comprises an indication of whether the update is with or without an override status.

According to a disclosed embodiment, the one or more processors are further configured to perform the operations of: updating the ECU software regardless of whether the vehicle is in the first mode of operation when the update received with the override status.

According to a disclosed embodiment, a method may be implemented far opportunistically updating ECU software in a vehicle. The method may comprise: receiving, at a controller in a vehicle, a wireless transmission indicating a need to update software running on at least one ECU in the vehicle; monitoring an operational status of the vehicle to determine whether the vehicle is in a first mode of operation in which an ECU software update is prohibited; delaying the ECU software update when the operational status is prohibited; continuing to monitor the operational status of the vehicle to determine whether the vehicle is in a second mode of operation in which the ECU software update is permitted; and enabling updating of the at least one ECU with the delayed ECU software update when it is determined that the vehicle is in the second mode of operation.

According to a disclosed embodiment continuing to monitor the operational status of the vehicle comprises repeatedly monitoring the operational status to of the vehicle according to a preestablished interval.

According to a disclosed embodiment, the wireless transmission indicating the need to update the software comprises an indication of whether the update is with or without an override status, and the method may further comprise: updating the ECU software regardless of whether the vehicle is an the first mode of operation when the update is received with the override status.

Aspects of the disclosed embodiments may include tangible computer-readable media that store software instructions that, when executed by one or more processors, are configured for and capable of performing and executing one or more of the methods, operations, and the like consistent with the disclosed embodiments. Also, aspects of the disclosed embodiments may be performed by one or more processors that are configured as special-purpose processor(s) based on software instructions that are programmed with logic and instructions that perform, when executed, one or more operations consistent with the disclosed embodiments.

It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only, and are not restrictive of the disclosed embodiments as claimed.

