System updates that were once occasional are now regularly required for devices of all kinds. If your device is connected to the internet, frequent patches are needed to keep up with security, feature enhancements, and bug fixes. Each patch is a test of special code the designer wrote to install updates – and also a chance for failure.

One failure during a software update can leave a device completely useless – basically a brick. Software update failures can lead to the loss of critically important data. In addition, they can cause costly, irreparable damage to a company’s reputation. When these dangers are combined with the increasing frequency of updates and criticality of data, planning for a failsafe update process can be considered a requirement. This involves more testing of the updates themselves, including the impact of power failure during the update, and a better method for installing software changes.

There’s one guiding tool that will help embedded developers design safer updates, and its ACID.

What is ACID?

The ACID acronym is a collection of properties designed to improve data fail-safety. ACID is used by database vendors, who know how important it is to perform an operation perfectly only once. This includes, for example, mortgage check funds which need to be withdrawn from an account and deposited with the loan company in one atomic operation.

According to ACID, a procedure should be atomic, consistent, isolated, and durable. Those same requirements can be used to help bulletproof a system update.

Atomicity – For an atomic update, transactions are all or nothing. This means that all of the data is written (or modified) at once, with no partial operations. This is the case whether the system update involves a single file, or multiple.

Consistency – Only valid data is saved. Consistency is applied to the individual files, mainly by requiring that they be valid. In other words, no download errors or media bit flips are allowed. For that matter, changes should be validated after they are applied, perhaps by performing a cyclic redundancy check of the resulting files, reverting to the previous state upon any failure.

Isolation – Transactions that are isolated do not affect each other. In contrast, performing an update while the embedded system is still writing other data to the media increases the likelihood of failure.

Durability – It’s important to make sure that written data is not lost. Any update process should therefore have the ability to recover from interruption. Most of the time errors in updates are due to a power failure – but a media error, failed cyclic redundancy check, or other exception could be to blame.

Whitepaper: Avoiding the brick

Security challenges and bug fixes are causing modern embedded devices to be updated more frequently than ever before, with more than 80% receiving updates yearly and 34% up to once a month. When a system update fails, the consequences range from trying again, all the way to a complete failure to boot – known as the brick.

The ACID acronym is a useful tool. But it’s just one part of a larger puzzle in keeping embedded devices safe from failed updates. The risk of complete failure can be mitigated through solutions that require extensive testing and rework, taking developers away from tasks that add customer value. But with the help of things like a transactional file system, any size and scope of system update can be handled seamlessly. A power failure or other interruption will never result in a brick, and no major changes to the application are required.

Download this whitepaper for information on how updates can go wrong, as well as the protections that are available in even minimal embedded environments.

Final thoughts

With updates to embedded devices occurring so frequently, it’s important to take steps in ensuring the updates don’t brick a device. The alternative? The risk of losing critical data, and the costly process of recovering the device. The ACID acronym is one tool for developers to use in achieving better fail-safety.