bulat-icon  Articles  
 
 

[+]  Articles

 
     
   
 

Worried about your software upgrade?

The goal of this article is helping you to in selecting SW upgrade method through following
 
  System on module  SW upgrade - The unavoidable process in embedded system  
  System on module  Define your product  
  arrow  Embedded system Boot binaries  
  arrow  Define Thumb rules for SW upgrade  
  arrow  SW upgrade Categories and Types  
  arrow  SW upgrade method selection flow  
  arrow  Conclusion  
 

SW upgrade - The unavoidable process in embedded system

Tell us about your product and we'll give you right SW upgrade method for it!.
Whichever embedded product you are having, upgrading SW on that is unavoidable. This upgrade fulfills both the producer and consumer of that product by doing followings
  • Running latest version of SW.
  • Getting rid of bugs in current running SW
  • Making use of new/reserved HW features in product
top-icon
top-icon

Define your product

 
Before thinking about SW upgrade method, first describe your product features, capabilities
  • Hardware features available for user intervention : Headless or Multilple Heads (i.e Displays), Audio, KeyBoard and Mouse interface
  • Media/Connectivity available for upgrade: USB host, Serial Port, Ethernet, WiFi
  • Storage size and Size of boot binaries

Embedded system Boot binaries

 
Following are list of common boot binaries present in embedded system
top-icon
 
top-icon

Bootloader - Not an upgradeable one ?

You may have this question "What? Bootloader can't be upgraded?". The answer is "No. it can be upgraded". But our recommendation is to not upgrade it.
Always keep your basic bootloader very simple and small. There should be no reason to update that once you release the product to market.
Because bootloader is the first SW running in your product when it s powered on. If the upgraded bootloader is a false one (or malfunctioning), then your product will become a brick. There are the some ways to overcome this. One is split your bootloader into two binaries (for example MLO and u-boot.bin) and keep the first one fixed (i.e non-upgradeable) and second one upgradeable.

Define Thumb rules for SW upgrade

It is always good to define output of a process by setting rules to that. Following are my thumb rules for SW upgrade.
Rule 1: It should be an atomic one. Basically by atomic I mean, either you update to the new one or stay where you were before you started the update. You should NOT GO INTO an unknown state
Rule 2: SW upgrade should not affect the functionality of the product. Worst case, It has to intimate the user that "system is not accessible till completion of SW upgrade"
Rule 3: When SW is upgraded and functionality is not met, it has to rollback to previous SW
Rule 4: Whether the SW upgrade is success or not, it has to log the details in the product
top-icon

SW upgrade Categories and Types

There are N number of methods for SW upgrade. Here I am listing those in following categories
  • User Intervention
  • Storage device Size for boot binaries
  • Media/Connectivity options available on the product
  • Boot binaries upgradeable

Types of SW upgrade mode in terms of user intervention

  • Manual upgrade
  • Auto upgrade

Types of SW upgrade mode in terms of storage size

  • Single Copy
  • Fail-safe mode
  • Dual Copy mode

Types of SW upgrade mode in terms of media/connectivity options available in product

  • Over The Air (OTA) mode
  • non-OTA (i.e non network connection) mode

Types of SW upgrade mode in terms of binaries

  • Full (i.e all binaries) upgrade
  • Part (i.e selected binaries) upgrade
Following table gives you the overall picture of sw upgrade methods with its risks and limitations. Advantage of each sw upgrade method can be droved with these two (risk and limitation) inputs.
Sl.No Criteria Mode Risk Limitation Suitable for
1 User Interaction Manual Unable to do SW upgrade when product in human non-accessible area
  • Human resource is involved
  • Cost for upgrading matters when human resource needs to travel for this
number of products is in small count (1-100)
2 Auto number of products is in large count(>100)
3 Storage Size and size of boot binaries Single Copy
  • When SW upgrade is interrupted or functionality not met after upgrade, product will become useless until it is recovered manually
  • Always we have one version of SW
  • Rolling back to previous version can not be done
  • Can't upgrade all binaries.
Very small amount of storage space for boot binaries
4 Fail-safe
  • When SW upgrade is interrupted or functionality not met after upgrade, product will become useless until it is recovered itself by doing SW upgrade again
  • Rolling back to previous version can not be done.
When storage size is more than but not double the amount of boot binaries.
5 Dual Copy
  • At a time, we can have two versions of SW only
When storage size is double the amount of boot binaries.
6 media/connectivity options available in product Over The Air (OTA) network devices
7 non-OTA non network devices
8 Binaries Full upgrade
  • Entire binaries has to be upgraded always
  • SW upgrading takes more time
  • Preparing upgrade image and transferring takes more time
  • Very small amount of storage space for boot binaries
  • Any binary upgrade or all binary upgrade requirement.
9 Part upgrade
  • Only specific binaries can be upgraded
When storage size is more than but not double the amount of boot binaries.
top-icon

SW upgrade method selection flow

top-icon
top-icon

Conclusion

Now you have the basic details of SW upgrade in Embedded System. In older days , product owners used to choose either Fail-Safe mode or Single Copy mode to upgrade full/part binaries due to storage size (NOR/NAND flash) limitation. Its the right time to choose the right upgrade method instead of just blindly following the old methods.
 
Wait for next article to have more details on SW upgrade